On Thu, Jan 14, 2016 at 2:52 PM, Alex Williamson
[off-list ref] wrote:

On Thu, 2016-01-14 at 14:03 +0800, Jike Song wrote:

quoted

On Wed, Dec 16, 2015 at 12:38 PM, Alex Williamson
[off-list ref] wrote:

quoted

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

Thanks! - that addressed my question :)

By the way, my previous assumption(consulting /proc/<pid>/pagemap)
apparently doesn't work: one cannot assume a usespace buffer is
physically continuous.


-- 
Thanks,
Jike