Re: [PATCH rc v2] iommu/arm-smmu-v3: Fix inconsistent ATS state tracking

[Pranjal Shrivastava <praan@google.com>]

On Wed, May 06, 2026 at 08:19:43PM +0000, Pranjal Shrivastava wrote:
> On Wed, May 06, 2026 at 06:46:30AM -0300, Jason Gunthorpe wrote:
> > On Tue, May 05, 2026 at 10:32:40PM +0000, Pranjal Shrivastava wrote:
> > > The PF shows no ATS Cap:
> > 
> 
>  3. Finally, if the PCIe spec actually allows VFs to enable ATS even
>     when the PF's ATS is disabled (but is ATS capable), then we might
>     need to ensure the PF is initialized with a valid STU even when its
>     ATS Enable bit is disabled, to allow enable_pci_ats() to pass for VFs
> 

Correction: This is what happens currently in the happy path, the STU is
set and we only clear the enable bit in the ATS control reg in 
pci_ats_disable.

> I'll dig into the PCIe ATS spec to confirm regarding PF/VF dependencies.
> 
> But from an initial understanding, I believe 3 is the correct way to go.
> If a device is ATS capable (i.e. PF & VF both present ATS capability),
> We shall allow PFs to attach to Identity domain and disable ATS while
> while allowing VFs to enable and use ATS.

The kernel seems to allow this today, during PF probe the PF's STU is
set regardless of it's ATS being enabled. Thus, a VF can use ATS even if
it's PF disables ATS. (Given that the ATS capability is presented
uniformly in both).

We are seeing a weird case due to a pci_ats_quirk coming into action.

Thanks
Praan