On Wed, Oct 07, 2015 at 10:31:04AM -0600, Alex Williamson wrote: > It sounds like a separate vfio iommu backend from type1, one that just > pins the page and returns the bus address. The curse and benefit would > be that existing type1 users wouldn't "just work" in an insecure mode, > the DMA mapping code would need to be aware of the difference. Still, I > do really prefer to keep vfio as only exposing a secure, iommu protected > device to the user because surely someone will try and users would > expect that removing iommu restrictions from vfio means they can do > device assignment to VMs w/o an iommu.
What I had in mind is rather reusing vfio code. What is needed is all the logic for handling device reset, protecting BARs and config space regions, MSI/MSI-X and device-specific work-arounds. Also, all the interface things such as eventfd. But I don't think it should be the same char device as vfio - /dev/vfio/vfio is world-accessible - should be a separate non-world accessible device, maybe /dev/vfio/noiommu. This will ensure e.g. qemu does not attempts to use it automatically. -- MST -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
