Re: [PATCH 03/11] iommu: Compute iommu_groups properly for PCIe switches

[Jason Gunthorpe <jgg@nvidia.com>]

On Thu, Jul 17, 2025 at 03:25:35PM -0400, Donald Dutile wrote:
> > What does a multi-function root port with different ACS flags even
> > mean and how should we treat it? I had in mind that the first root
> > port is the TA and immediately goes the IOMMU.
> > 
> I'm looking for clarification what you are asking...
> 
> when you say 'multi-function root port', do you mean an RP that is a function
> in a MFD in an RC ?  other?  A more explicit (complex?) example be given to
> clarify?

A PCIE Root port with a downstream bus that is part of a MFD.

Maybe like this imaginary thing:

00:1f.0 ISA bridge: Intel Corporation C236 Chipset LPC/eSPI Controller (rev 31)
00:1f.2 Memory controller: Intel Corporation 100 Series/C230 Series Chipset Family Power Management Controller (rev 31)
00:1f.3 Audio device: Intel Corporation 100 Series/C230 Series Chipset Family HD Audio Controller (rev 31)
00:1f.4 SMBus: Intel Corporation 100 Series/C230 Series Chipset Family SMBus (rev 31)
00:1f.5 PCI bridge: Intel Corporation 100 Series/C230 Series Chipset Family PCI Express Root Port #17 (rev f1)

> IMO, the rule of MFD in an RC applies here, and that means the per-function ACS rules
> for an MFD apply -- well, that's how I read section 6.12 (PCIe 7.0.-1.0-PUB).
> This may mean checking ACS P2P Egress Control.  Table 6-11 may help wrt Egress control bits & RPs & Fcns.

The spec says "I donno"

 Implementation of ACS in RCiEPs is permitted but not required. It is
 explicitly permitted that, within a single Root Complex, some RCiEPs
 implement ACS and some do not. It is strongly recommended that Root
 Complex implementations ensure that all accesses originating from
 RCiEPs (PFs, VFs, and SDIs) without ACS support are first subjected to
 processing by the Translation Agent (TA) in the Root Complex before

"strongly recommended" is not "required".

> If no (optional) ACS P2P Egress control, and no other ACS control, then I read/decode
> the spec to mean no p2p btwn functions is possible, b/c if it is possible, by spec,
> it must have an ACS cap to control it; ergo, no ACS cap, no p2p capability/routing.

Where did you see this? Linux has never worked this way, we have
extensive ACS quirks specifically because we've assumed no ACS cap
means P2P is possible and not controllable.

Jason