[dpdk-dev] VFIO no-iommu
Alex Williamson
alex.williamson at redhat.com
Thu Jan 14 07:52:29 CET 2016
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
More information about the dev
mailing list