[vfio-users] IOMMU page table of QEMU vfio device passthrough

[Alex Williamson]

On Tue, 5 Jun 2018 15:16:55 -0700
Huaicheng Li <huaicheng at cs.uchicago.edu> wrote:

> Hi,
> 
> I assigned a PCIe device to my QEMU VM and learnt that in this case, IOMMU
> maintains GPA->HPA translation. What I
> want to achieve is to pass commands with host physical addresses to the
> device from inside the VM and see if the DMA
> will successfully do that for me.
> 
> (1). How does VFIO setup the GPA->HPA mapping for each DMA buffer? which
> source file can I refer to for such information?
> Currently I'm looking at VFIO_IOMMU_DMA_MAP, it seems it only maps the base
> address of QEMU guest memory region to
> IOVA. Does this mean that later all GPA->HPA translation are based on that
> plus some offsets?

Unless you enable an emulated IOMMU in the guest, VFIO does not setup
mappings per DMA buffer, it maps all of guest physical memory through
the IOMMU so that the device can DMA to any GPA and it's already
mapped.  We call this transparent assignment, the guest can perform DMA
without any knowledge of or interaction with the host IOMMU.  If you do
configure an emulated IOMMU, then the guest device driver will
configure a mapping through the gIOMMU, which will create a mapping
through the pIOMMU.  In either case, all of this happens through
MemoryListeners in the vfio code. It's mostly a difference in which
AddressSpace the device is using.

> (2). Is it possible for me to disable IOMMU page tables as I just want to
> give the device a host physical address?

It's software, anything is possible, but you'll need to subvert
something to do that for you.  One subversion we have in place is the
no-iommu mode of vfio, which does not provide any mapping services and
taints the host kernel.  This mode is explicitly not intended for
device assignment, you'll be lucky to boot a VM at all and it will
probably take the host down in the process, thus the tainting.  Please
don't report bugs against unsafe options that explicitly taint the
kernel as an indication not to use them.  Thanks,

Alex