On Fri, 2015-11-06 at 13:29 +0100, Joerg Roedel wrote: > Hi Alex, > > On Thu, Nov 05, 2015 at 10:54:39AM -0700, Alex Williamson wrote: > > We have a couple things in-flight that are trying to make use of IOMMU > > groups, independent of the rest of the IOMMU API. One is the proposed > > VFIO No-IOMMU hack that will create an IOMMU group for a non-IOMMU > > backed device in order to make it operate within vfio and exposed via > > vfio-pci: > > > > https://lkml.org/lkml/2015/11/4/437 > > Do you really need iommu-groups for non-IOMMU vfio backend? VFIO has its > own representation of groups (iirc they map 1-1 to iommu-groups). Can > this concept in VFIO not be made more independent of iommu-groups? > > I think having iommu-groups in sysfs without an iommu in the system is > pretty confusing for the user. Not to say that the usual iommu grouping > code makes no sense anymore, as there is no isolation at all :)
Hi Joerg, VFIO is really built on iommu groups, so making a vfio group independent of iommu groups is a difficult proposition. With introducing the no-iommu vfio code, I accept that people are going to run userspace drivers without iommu protection, regardless of whether it's supportable. By using the vfio device interface, we're at least pushing them towards code that does have a supported use case. So my goal there is to enable no-iommu mode in a way that is compact (I'm only willing to invest limited lines of code to enable this) and does not undermine the foundation of vfio. I also do everything I can to make it clear that this is unsafe, from the naming of the opt-in module parameter to the tainting of the kernel when a no-iommu group is created to the dev_warn with that group creation and later when the device is opened, using a differently named vfio device node for the group, and allowing only a no-iommu IOMMU backend for the group. There is no chance that a user can accidentally operate on a no-iommu vfio group and there are breadcrumbs left behind even in the normal process of using them. Also, as I mentioned previously, the lifetime of this no-iommu group is tied to the device being bound to the vfio driver, so no other drivers would have access to the iommu group and the user has already had to opt-in their system and generated a dmesg log and kernel taint before they even get the chance to be confused by that iommu group. Thanks, Alex _______________________________________________ iommu mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/iommu
