On Tue, Sep 09, 2025 at 03:27:02PM -0500, Bjorn Helgaas wrote: > > Instead the current algorithm always creates unique single device groups > > for this topology. It happens because the pci_device_group(DSP) > > immediately moves to the USP and computes pci_acs_path_enabled(USP) == > > true and decides the DSP can get a unique group. The pci_device_group(A) > > immediately moves to the DSP, sees pci_acs_path_enabled(DSP) == false and > > then takes the DSPs group. > > s/takes the DSPs group/takes the DSP's group/ (I guess?) yeah > > While ACS on root ports is underspecified in the spec, it should still > > function as an egress control and limit access to either the MMIO of the > > root port itself, or perhaps some other devices upstream of the root > > complex - 00:17.0 perhaps in this example. > > Does ACS have some kind of MMIO-specific restriction? I guess no, the text could be more generic here. > > As grouping is a security property for VFIO creating incorrectly narrowed > > groups is a security problem for the system. > > I.e., we treated devices as being isolated from P2PDMA when they > actually were not isolated, right? More isolation => smaller > (narrower) IOMMU groups? Yes > > Revise the design to solve these problems. > > > > Explicitly require ordering, or return EPROBE_DEFER if things are out of > > order. This avoids silent errors that created smaller groups and solves > > problem #1. > > If it's easy to state, would be nice to say what ordering is required. > The issue mentioned above was "discovering a downstream device before > its upstream", so I guess you want to discover upstream devices before > downstream? yes > Obviously PCI enumeration already works that way, so > IOMMU group discovery must be a little different. iommu group discovery is driven off of iommu probing which can happen in enough different ways that it needs to be checked. I will fix the other notes Thanks, Jason