On Thu, Jan 14, 2016 at 2:52 PM, Alex Williamson
wrote:
> On Thu, 2016-01-14 at 14:03 +0800, Jike Song wrote:
>> On Wed, Dec 16, 2015 at 12:38 PM, Alex Williamson
>> 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//pagemap)
apparently doesn't work: one cannot assume a usespace buffer is
physically continuous.
--
Thanks,
Jike