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
