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

[Pranjal Shrivastava <praan@google.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?
> 

Hmm.. you mean we should fail the VF attach if it's PF's ATS isn't
enabled?

I agree prepare_ats is called regardless on every device and we return
early without setting the STU if (dev->is_virtfn) but the catch is we
never check for pci_prepare_ats's return value in probe_device :/
(The PF might be untrusted or non ATS capable).

Here's the EXACT failing case:

1. arm_smmu_probe_device(PF) -> we call pci_prepare_ats & ignore retval
2. The PF attaches to Identity domain (pci_enable_ats skipped, no logs)
3. We create VFs and try to assign them (new group -> unmanaged domain)
4. We try to enable ATS in attach_commit, fail and see the failure log
5. arm-smmu-v3 driver tracks the state as "ATS enabled" for VF
6. We try to disable ATS which was never enabled and hit the WARN

The catch is in step 1, pci_prepare_ats(PF) returned -EINVAL as either
the ATS capability didn't exist OR the device was untrusted but the
driver let it slide (ignored the retval in probe_device).
I'll debug further to see which one is it (because in that case
arm_smmu_ats_supported should've failed too).

Thanks,
Praan