On Fri, Jun 24, 2022 at 07:31:47PM +0100, Robin Murphy wrote: > > > Oh, physical platforms with mixed IOMMUs definitely exist already. The main > > > point is that while bus_set_iommu still exists, the core code effectively > > > *does* prevent multiple drivers from registering - even in emulated cases > > > like the example above, virtio-iommu and VT-d would both try to > > > bus_set_iommu(&pci_bus_type), and one of them will lose. The aspect which > > > might warrant clarification is that there's no combination of supported > > > drivers which claim non-overlapping buses *and* could appear in the same > > > system - even if you tried to contrive something by emulating, say, VT-d > > > (PCI) alongside rockchip-iommu (platform), you could still only describe one > > > or the other due to ACPI vs. Devicetree. > > > > Right, and that is still something we need to protect against with > > this ops check. VFIO is not checking that the bus's are the same > > before attempting to re-use a domain. > > > > So it is actually functional and does protect against systems with > > multiple iommu drivers on different busses. > > But as above, which systems *are* those? IDK it seems wrong that the system today will allow different buses to have different IOMMU drivers and not provide a trivial protection check. > FWIW my iommu/bus dev branch has got as far as the final bus ops removal and > allowing multiple driver registrations, and before it allows that, it does > now have the common attach check that I sketched out in the previous > discussion of this. If you want to put the check in your series that seems fine too, as long as we get it in the end. > It's probably also noteworthy that domain->ops is no longer the same > domain->ops that this code was written to check, and may now be different > between domains from the same driver. Yes, the vfio check is not good anymore. Jason
