Messages in this thread | | | Date | Mon, 15 Nov 2021 18:35:37 +0000 | Subject | Re: [PATCH 02/11] driver core: Set DMA ownership during driver bind/unbind | From | Robin Murphy <> |
| |
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.
> 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.
Robin.
> Or, a 'dev_configure_dma()' function that is roughly: > > if (dev->bus->dma_configure) { > ret = dev->bus->dma_configure(dev); > if (ret) > return ret; > if (!drv->suppress_auto_claim_dma_owner) { > ret = iommu_device_set_dma_owner(dev, DMA_OWNER_KERNEL, > NULL); > if (ret) > ret; > } > } > > And a pair'd undo. > > This is nice because we can enforce dev->bus->dma_configure when doing > a user bind so everything holds together safely without relying on > each bus_type to properly implement security. > > Jason > _______________________________________________ > iommu mailing list > iommu@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/iommu >
| |