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, Alex
