[dpdk-dev] VFIO no-iommu

[O'Driscoll, Tim]

> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Alex Williamson
> Sent: Friday, December 11, 2015 11:03 PM
> To: Vincent JARDIN; dev at dpdk.org
> Subject: Re: [dpdk-dev] VFIO no-iommu
> 
> On Fri, 2015-12-11 at 23:12 +0100, Vincent JARDIN wrote:
> > Thanks Thomas for putting back this topic.
> >
> > Alex,
> >
> > I'd like to hear more about the impacts of "unsupported":
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commi
> > t/?id=033291eccbdb1b70ffc02641edae19ac825dc75d
> >    Use of this mode, specifically binding a device without a native
> >    IOMMU group to a VFIO bus driver will taint the kernel and should
> >    therefore not be considered supported.
> >
> > It means that we get ride of uio; so it is a nice code cleanup: but
> > why
> > would VFIO/NO IOMMU be better if the bottomline is "unsupported"?
> 
> How supportable do you think the uio method is?  Fundamentally we have
> a userspace driver doing unrestricted DMA; it can access and modify any
> memory in the system.  This is the reason uio won't provide a mechanism
> to enable MSI and if you ask the uio maintainer, they don't support DMA
> at all, it's only intended as a programmed IO interface to the device.
>  Unless we can sandbox a user owned device within an IOMMU protected
> container, it's not supportable.  The VFIO no-iommu mode can simply
> provide you that unsupported mode more easily since it leverages code
> from the supported mode, which is IOMMU protected.  Thanks,

Thanks for clarifying.

This does seem like it would be useful for DPDK. We're doing some further investigation to see if it works out of the box with DPDK or if we need to make any changes to support it.

Thomas highlighted that your original commit for this had been reverted. What specifically would you need from us in order to re-submit the VFIO No-IOMMU support?


Tim

> 
> Alex