On Mon, Nov 15, 2021 at 06:35:37PM +0000, Robin Murphy wrote: > On 2021-11-15 15:56, Jason Gunthorpe via iommu wrote: > > On Mon, Nov 15, 2021 at 03:37:18PM +0000, Robin Murphy wrote: > > > > > IOMMUs, and possibly even fewer of them support VFIO, so I'm in full > > > agreement with Greg and Christoph that this absolutely warrants being scoped > > > per-bus. I mean, we literally already have infrastructure to prevent drivers > > > binding if the IOMMU/DMA configuration is broken or not ready yet; why would > > > we want a totally different mechanism to prevent driver binding when the > > > only difference is that that configuration *is* ready and working to the > > > point that someone's already claimed it for other purposes? > > > > I see, that does make sense > > > > I see these implementations: > > > > drivers/amba/bus.c: .dma_configure = platform_dma_configure, > > drivers/base/platform.c: .dma_configure = platform_dma_configure, > > drivers/bus/fsl-mc/fsl-mc-bus.c: .dma_configure = fsl_mc_dma_configure, > > drivers/pci/pci-driver.c: .dma_configure = pci_dma_configure, > > drivers/gpu/host1x/bus.c: .dma_configure = host1x_dma_configure, > > > > Other than host1x they all work with VFIO. > > > > Also, there is no bus->dma_unconfigure() which would be needed to > > restore the device as well. > > Not if we reduce the notion of "ownership" down to "dev->iommu_group->domain > != dev->iommu_group->default_domain", which I'm becoming increasingly > convinced is all we actually need here. The group will be on the default_domain regardless if a kernel driver is bound or not, so the number of bound kernel drivers still needs to be tracked and restored. > > So, would you rather see duplicated code into the 4 drivers, and a new > > bus op to 'unconfigure dma' > > The .dma_configure flow is unavoidably a bit boilerplatey already, so > personally I'd go for having the implementations call back into a common > check, similarly to their current flow. That also leaves room for the bus > code to further refine the outcome based on what it might know, which I can > particularly imagine for cleverer buses like fsl-mc and host1x which can > have lots of inside knowledge about how their devices may interact. bus specific variation does not fill me with confidence - there should not be bus specific variation on security principles, especially when the API is supporting VFIO and the like. How can we reason about that? Jason
