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

[Nicolin Chen <nicolinc@nvidia.com>]

On Tue, May 05, 2026 at 01:11:26PM -0300, Jason Gunthorpe wrote:
> On Mon, May 04, 2026 at 07:33:07PM +0000, Pranjal Shrivastava wrote:
> 
> > > > The issue was exposed under heavy load when running a VFIO-based DMA map
> > > > stress test: iova_stress [1]
> > > 
> > > I wonder what's the real reason for pci_enable_ats() to fail:
> > > 
> > 
> > Yes, It's the dev->is_virtfn case (the one you suspect below)
> 
> Oh.... This is a much larger problem then
> 
> The VF should not fail to enable ATS, that is a meaningful bug, I'm
> not sure why are are just discovering this?
> 
> It looks like the PF unconditionally calls pci_prepare_ats() during
> arm_smmu_probe_device(), so how does this happen:
> 
> > >         if (dev->is_virtfn) {
> > >                 pdev = pci_physfn(dev);
> > >                 if (pdev->ats_stu != ps)
> > >                         return -EINVAL;		// maybe this one?
> 
> ??
> 
> So, I think the right error handling for a case that shouldn't happen is
> to fail the attachment not to try to continue it broken?

Inspired by your inputs, I found that pci_prepare_ats() demands in
kdocs:

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

But it returns 0 directly on dev->is_virtfn.

I wonder if this function itself should just fail if dev->is_virtfn
and !pci_physfn(dev)->ats_stu?

Then, arm_smmu_probe_device() must fail if pci_prepare_ats() fails.

Nicolin