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

[Pranjal Shrivastava <praan@google.com>]

On Wed, May 06, 2026 at 10:20:15PM +0000, Samiullah Khawaja wrote:
> > 
> > Thus, this sequence occurs:
> > 
> > 1. The Intel quirk sets pdev->ats_cap = 0 for the PF at boot.
> > 2. pci_prepare_ats(PF) fails during arm_smmu_probe_device() as the
> >   quirk causes pci_ats_supported to return false & PF->ats_stu
> >   remains 0. (arm-smmu-v3 ignores the failure)
> 
> Ok that explains how PF stu is zero.
> > 
> > 3. PF attaches to identity domain: pci_enable_ats is skipped
> > 4. VF's arm_smmu_probe_device returns early from pci_prepare_ats() due
> >   to the if (dev->is_virtfn) return 0; check
> > 
> > 5. SMMU calls pci_ats_supported() for the VF in attach_prepare() which
> >   returns true as the quirk hasn't been called for the VF yet.
> >   The SMMU driver sets state->ats_enabled = true
> > 
> > 6. We call pci_enable_ats which hits the STU mismatch (PF never sets it)
> > 7. Later while disabling ATS for VF via pci_disable_ats, we hit the WARN
> > 
> > I guess we must think about the following:
> > 
> > 1. Check return values of pci_enable_ats / pci_prepare_ats in SMMUv3
> > 2. PCIe core to provide a proper ATS flag that iommu driver can rely on
> >   and maybe define a policy around pci_ats_supported() to make sure it
> >   also handles such quirks in pci_ats_supported().
> 
> It seems like that ats_supported() checking only ats_cap of the VF is
> not enough, since ATS can be enabled for a VF only when the stu matches
> with the PF? So even if ats_supported() for the VF returns true, its not
> really supported if the stu doesn't match. And the stu would be set
> properly if the PF had ats_cap. Should the ats_supported() check for
> the ats_cap for the PF also?
> 

I think yes. We should add that OR we should be checking for PF's ATS
cap while probing VFs to handle such quirks. The main problem is that
the quirk isn't applied to the VF *before* the IOMMU attach. 

> We can check the PF ats_cap in the ats_supported() or handle the
> enable_ats() error in arm smmuv3. Intel and AMD drivers seems to be
> handling the error.

I guess if pci_ats_supported() is fixed arm smmuv3 would stop hitting
that warning. Although, I agree that we should be checking the retval of
prepare_ats & enable_ats in arm-smmu-v3.

Thanks,
Praan