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

[Jason Gunthorpe <jgg@ziepe.ca>]

On Mon, May 11, 2026 at 04:07:10PM +0000, Pranjal Shrivastava wrote:
> This is actually a little weird/funny...
> 
> For PF: pci_prepare_ats fails as it sees a null ats_cap (quirk applied)
>         and fails at pci_ats_supported().
> 
> For VF: pci_prepare_ats bails out early if (dev->is_virtfn):
> 
> /**
>  * pci_prepare_ats - Setup the PS for ATS
>  * @dev: the PCI device
>  * @ps: the IOMMU page shift
>  *
>  * This must be done by the IOMMU driver on the PF before any VFs are created to
>  * ensure that the VF can have ATS enabled.
>  *
>  * Returns 0 on success, or negative on failure.
>  */
> int pci_prepare_ats(struct pci_dev *dev, int ps)
> {
> 	u16 ctrl;
> 
> 	if (!pci_ats_supported(dev))
> 		return -EINVAL;
> 
> 	if (WARN_ON(dev->ats_enabled))
> 		return -EBUSY;
> 
> 	if (ps < PCI_ATS_MIN_STU)
> 		return -EINVAL;
> 
> 	if (dev->is_virtfn) <---- THIS
> 		return 0;

I would check the PF STU here and fail if wrong, like pci_enable_ats()
does. The purpose of prepare is to make the STU right, so it is
completely logical.

> Ideally, in such cases I'd want VFs to fail at pci_ats_supported itself

The quirk should cause pci_ats_supported to fail.

My observation is that pci_prepare_ats() shuld also always fail if it
cannot setup the STU, meaning the VF should do more than just return 0
since enable_ats is doing more.

> if (dev->is_virtfn && !pci_ats_supported(pci_physfn(dev)))
>          return false;
> 
> OR 2. we could have pci_ats_supported call into some ats quirk helper.

Both of these seem like good options to fix the quirk. The first is
probably OK

> We need pci_ats_supported to fail here because if we contain the failure
> in pci_prepare_ats, we'll see pci_ats_supported return success in attach
> which will make arm_smmu_v3 believe that ATS is supported..

Yes, that's right for the quirk issue.

Jason