qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v5 08/11] spapr-iommu: add SPAPR VFIO IOMMU devi


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH v5 08/11] spapr-iommu: add SPAPR VFIO IOMMU device
Date: Thu, 10 Apr 2014 14:13:56 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0


On 07.04.14 06:07, Alexey Kardashevskiy wrote:
On 04/03/2014 11:17 PM, Alexander Graf wrote:
On 12.03.14 06:52, Alexey Kardashevskiy wrote:
This adds SPAPR VFIO IOMMU device in order to support DMA operations
for VFIO devices.
Sorry if this has been mentioned before, but why exactly do you need a
separate IOMMU for VFIO? Couldn't the existing IOMMU backend drive things?
Well... Since I started VFIO on SPAPR, the emulated and VFIO IOMMU became
almost the same thing and I'll rework that too before I post things again.

However one difference still remains - IOMMU for emulated PCI and VIO keeps
a TCE table (allocated in QEMU or mmap'ed from the host kernel) and VFIO
IOMMU works with the table which is allocated and owned by the host kernel.

Since TCE tables are used only by devices, the IOMMU translation callback
is never called by VFIO devices and that's ok and I checked - it works.

So I either need a property in the IOMMU device to tell it is TCE table and
MemoryRegionIOMMUOps::translate() are required. Or a new IOMMU device
class. What to choose?

We need to handle in-kernel TCE tables with the emulated device IOMMU as well, so I'd

Oh. btw. There is H_GET_TCE now which I have to implement for VFIO :( This
will never ever end.

... which means you get H_GET_TCE for free as well ;).


Alex




reply via email to

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