On 9/10/25 1:34 PM, Jason Gunthorpe wrote:
On Tue, Sep 09, 2025 at 04:43:50PM -0500, Bjorn Helgaas wrote:
+/*
+ * The spec is not clear what it means if the capability bit is 0. One view is
+ * that the device acts as though the ctrl bit is zero, another view is the
+ * device behavior is undefined.
+ *
+ * Historically Linux has taken the position that the capability bit as 0 means
+ * the device supports the most favorable interpretation of the spec - ie that
+ * things like P2P RR are always on. As this is security sensitive we expect
+ * devices that do not follow this rule to be quirked.
Interpreting a 0 Capability bit, i.e., per spec "the component does
not implement the feature", as "the component behaves as though the
feature is always enabled" sounds like a stretch to me.
I generally agree, but this is how it is implemented today.
I've revised this text, I think it is actually OK and supported by the
spec, but it is subtle:
/*
* The spec has specific language about what bits must be supported in an ACS
* capability. In some cases if the capability does not support the bit then it
* really acts as though the bit is enabled. e.g.:
*
* ACS P2P Request Redirect: must be implemented by Root Ports that support
* peer-to-peer traffic with other Root Ports
*
* Meaning if RR is not supported then P2P is definately not supported and the
* device is effectively behaving as if RR is set.
*
* Summarizing the spec requirements:
* DSP Root Port MFD
* SV M M M
* RR M E E
* CR M E E
* UF M E N/A
* TB M M N/A
* DT M E E
* - M=Must Be Implemented
* - E=If not implemented the behavior is effecitvely as though it is enabled.
*
* Therefore take the simple approach and assume the above flags are enabled
* if the cap is 0.
*
* ACS Enhanced eliminated undefined areas of the spec around MMIO in root ports
* and switch ports. If those ports have no MMIO then it is not relevant.
* PCI_ACS_UNCLAIMED_RR eliminates the undefined area around an upstream switch
* window that is not fully decoded by the downstream windows.
*
* Though the spec is written on the assumption that existing devices without
* ACS Enhanced can do whatever they want, Linux has historically assumed what
* is now codified as PCI_ACS_DSP_MT_RB | PCI_ACS_DSP_MT_RR | PCI_ACS_USP_MT_RB
* | PCI_ACS_USP_MT_RR | PCI_ACS_UNCLAIMED_RR.
*
* Changing how Linux understands existing ACS prior to ACS Enhanced would break
* alot of systems.
*
* Thus continue as historical Linux has always done if ACS Enhanced is not
* supported, while if ACS Enhanced is supported follow it.
*
* Due to ACS Enhanced bits being force set to 0 by older Linux kernels, and
* those values would break old kernels on the edge cases they cover, the only
* compatible thing for a new device to implement is ACS Enhanced supported with
* the control bits (except PCI_ACS_IORB) wired to follow ACS_RR.
*/
Sounds like a mess and might be worth an ECR to clarify the spec.
IMHO alot of this is badly designed for an OS. PCI SIG favours not
rendering existing HW incompatible with new revs of the spec, which
generally means the OS has no idea WTF is going on anymore.
For ACS it means the OS cannot accurately predict what the fabric
routing will be..
Jason
Exec summary: the spec is clear as mud wrt RP/RCs. ;-p
The above summary captures the proposed update conclusions to the spec,
and enables a good reference if a future conclusion is made that should require
another change in this area. Thanks for the added verbage for future reference.
- Don
