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

[Jason Gunthorpe <jgg@nvidia.com>]

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.

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.

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.

> 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.

> 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.

Jason