[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [PATCH v7 1/4] spapr_iommu: Make in-kernel TCE table opti

From: Alexey Kardashevskiy
Subject: Re: [Qemu-ppc] [PATCH v7 1/4] spapr_iommu: Make in-kernel TCE table optional
Date: Thu, 05 Jun 2014 23:10:40 +1000
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

On 06/05/2014 11:06 PM, Alexander Graf wrote:
> On 05.06.14 08:43, Alexey Kardashevskiy wrote:
>> On 06/05/2014 03:49 PM, Alexey Kardashevskiy wrote:
>>> POWER KVM supports an KVM_CAP_SPAPR_TCE capability which allows allocating
>>> TCE tables in the host kernel memory and handle H_PUT_TCE requests
>>> targeted to specific LIOBN (logical bus number) right in the host without
>>> switching to QEMU. At the moment this is used for emulated devices only
>>> and the handler only puts TCE to the table. If the in-kernel H_PUT_TCE
>>> handler finds a LIOBN and corresponding table, it will put a TCE to
>>> the table and complete hypercall execution. The user space will not be
>>> notified.
>>> Upcoming VFIO support is going to use the same sPAPRTCETable device class
>>> so KVM_CAP_SPAPR_TCE is going to be used as well. That means that TCE
>>> tables for VFIO are going to be allocated in the host as well.
>>> However VFIO operates with real IOMMU tables and simple copying of
>>> a TCE to the real hardware TCE table will not work as guest physical
>>> to host physical address translation is requited.
>>> So until the host kernel gets VFIO support for H_PUT_TCE, we better not
>>> to register VFIO's TCE in the host.
>>> This adds a bool @kvm_accel flag to the sPAPRTCETable device telling
>>> that sPAPRTCETable should not try allocating TCE table in the host kernel.
>>> Instead, the table will be created in QEMU.
>>> This adds an kvm_accel parameter to spapr_tce_new_table() to let users
>>> choose whether to use acceleration or not. At the moment it is enabled
>>> for VIO and emulated PCI. Upcoming VFIO support will set it to false.
>>> Signed-off-by: Alexey Kardashevskiy <address@hidden>
>>> ---
>>> This is a workaround but it lets me have one IOMMU device for VIO, emulated
>>> PCI and VFIO which is a good thing.
>>> The other way around would be a new KVM_CAP_SPAPR_TCE_VFIO capability but
>>> this needs kernel update.
>> Never mind, I'll make it a capability. I'll post capability reservation
>> patch separately.
> Just rename the flag from "kvm_accel" to "vfio_accel", set it to true for
> vfio and false for emulated devices. Then the spapr_iommu file can check on
> the capability (and default to false for now, since it doesn't exist yet).

Is that ok if the flag does not have to do anything with VFIO per se? :)

> That way you don't have to reserve a CAP today.

Why exactly cannot we do that today?

How do we proceed with the rest of this patchset? Thanks!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]