[dpdk-dev] VFIO no-iommu

Jike Song albcamus at gmail.com
Thu Jan 14 09:12:45 CET 2016

On Thu, Jan 14, 2016 at 2:52 PM, Alex Williamson
<alex.williamson at redhat.com> wrote:
> 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 at 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

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.


More information about the dev mailing list