On Thu, Jul 17, 2025 at 10:31:42PM -0400, Donald Dutile wrote: > > > 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. > > > e.g., Section 6.12.1.2 ACS Functions in SR-IOV, SIOV, and Multi-Function Devices > ... > ACS P2P Request Redirect: must be implemented by Functions that support peer-to-peer traffic with other Functions. > ^^^^ > > It's been noted/stated/admitted that MFDs have not followed the ACS > rules, and thus the quirks may/are needed. > > Linux default code should not be opposite of the spec, i.e., if no > ACS, then P2P is possible, thus all fcns are part of an IOMMU group. > The spec states that ACS support must be provided if p2p traffic > with other functions is supported. Linux is definately the opposite of this. Alex would you agree to reverse this logic for MFDs? If the MFD does not have ACS cap then the MFD does not do internal loopback P2P? I think that solves all the MFD related problems. Thanks, Jason
