Re: VFIO no-iommu

[Alex Williamson <alex.williamson@redhat.com>]

On Thu, 2016-01-14 at 14:03 +0800, Jike Song wrote:
> On Wed, Dec 16, 2015 at 12:38 PM, Alex Williamson
> <alex.williamson@redhat.com> wrote:
> > 
> > So it works.  Is it acceptable?  Useful?  Sufficiently complete?  Does
> > it imply deprecating the uio interface?  I believe the feature that
> > started this discussion was support for MSI/X interrupts so that VFs
> > can support some kind of interrupt (uio only supports INTx since it
> > doesn't allow DMA).  Implementing that would be the ultimate test of
> > whether this provides dpdk with not only a more consistent interface,
> > but the feature dpdk wants that's missing in uio. Thanks,
> > 
> Hi Alex,
> 
> Sorry for jumping in.  Just being curious, how does VFIO No-IOMMU mode
> support DMA from userspace drivers?  If I understand correctly, due to
> the absence of IOMMU, pcidev has to use physaddr to start a DMA
> transaction, but how it is supposed to get physaddr from userspace
> drivers, /proc//pagemap or something else?

Hi Jike,

vfio no-iommu does nothing to facilitate DMA mappings, UIO didn't
either and DPDK managed to work with that.  vfio no-iommu is meant to
be an enabler and provide a consistent vfio device model (with MSI/X
interrupts), but fundamentally the idea of a non-iommu protected, user
owned device capable of DMA is unsupportable.  This is why vfio no-
iommu taints the kernel.  With that in mind, one of the design goals is
to introduce as little code as possible for vfio no-iommu.  A new vfio
iommu backend with pinning and virt-to-bus translation goes against
that design goal.  I don't know the details of how DPDK did this with
UIO, but the same lack of DMA mapping facilities is present with vfio
no-iommu.  It really just brings the vfio device model, nothing more.
Thanks,

Alex