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

[Alex Williamson <alex.williamson@redhat.com>]

On Tue, 23 Sep 2025 09:32:18 -0300
Jason Gunthorpe <jgg@nvidia.com> wrote:

> On Mon, Sep 22, 2025 at 08:50:27PM -0600, Alex Williamson wrote:
> > That's not what the spec is doing.  We're misinterpreting it.  The
> > sections of the spec you're quoting are saying that if a MFD function
> > supports ACS it must support this specific p2p set of capability and
> > control bits unless the device does not support internal p2p.  
> 
> Bjorn raised that too, but it doesn't actually say that. The wording
> is meaningfully different from the preceeding section that does
> explicitly say the language only applies if the ACS cap is present.

What then is a "Multi-Function Device ACS Function".  I think we need
to take context from the parent and previous sections to understand
this applies to functions implementing the ACS extended capability.

> IMHO, from a spec perspective, prior to this language, internal MFD
> loopback was *undefined*.
> 
> You are advocating for a very pessimistic position that undefined must
> mean the worst interpretation for everyone. It doesn't, undefined
> means we don't know.

Right, we don't know if p2p is implemented, we're implementing a
security related feature, therefore we assume the worst case and allow
for quirks in instances where the vendor can vouch that p2p is not
possible.

> A big part of the argument here is that in the modern world the HW
> community has aligned that MFDs should not have internal loopback
> because it harms virtualization.
> 
> We are here a decade later and we can choose to require quirks on
> devices that choose to implement internal loopback, because they are
> certainly now the minority of HW.

This seems like optimistic speculation.

> > We've had NIC vendors implement an empty ACS capability to convey the
> > fact that the device does not support internal p2p.  There is precedent
> > for the interpretation I'm describing.  
> 
> IMHO it just shows Linux has the power to convince device vendors to
> do things.

And now we're effectively punishing vendors that have gone to this
effort to expose isolation by hand waving that it should exist by now...
 
> > Are we going to expect users to opt-in to securing their system?  
> 
> Since the grouping isn't working right today we are already
> effectively doing this.
> 
> All this is arguing that the burden shifts from people with modern
> systems to people with ancient systems.

AIUI there's a narrow case of downstream switch ports implemented as
separate slots that is misrepresented.  This should be fixed.  There's
also an effort here to consider both egress traffic (as done today) as
well as ingress traffic (new).  IMO this will inevitably cause
regressions and users may need to opt-in to make their grouping less
secure for previous compatibility.

Requiring users to opt-in to secure their system is fundamentally
different from requiring users to opt-in to a reduced isolation
paradigm.  Thanks,

Alex