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

[Jason Gunthorpe <jgg@ziepe.ca>]

On Mon, May 11, 2026 at 12:07:04PM +0000, Pranjal Shrivastava wrote:
> 
> > Thus the quirk should cover the VFs too and also disable ATS there.
> 
> I observe the quirk does apply VFs but after the VF's iommu attach
> because of how the pci_iov_add_virtfn() is written:

Ah, that seems to be the issue then :\

> While, we can move this quirk to be in fixup_early / fixup_header.
> I still think we should add checking the PF->ats_cap within 
> pci_ats_supported before bailing out happily (return 0) for VFs.

I feel like this should stay in prepare... supported is a differerent
thing. Maybe the quirk should be more directly tied to ats_supported
instead of whatever it is doing now? The ACS code calls directly into
quirks for example?
 
> > So I still think my original suggestion is appropriate, fail to probe
> > the iommu device if ats prepare fails (serious PCI layer bug, like
> > broken quirks) and fail to attach the domain of ats enable fails
> > (serious internal kernel malfunction since enable must succeed if
> > prepare succeeded)
> 
> I’m concerned that refusing to attach a device because it isn't ATS 
> capable is bit too aggressive.

Sorry, I was thinking prepare fails because it *fails*, prepare
succeeds if ATS is just not supported and won't ever be enabled.

But these odd cases where prepare sees ATS as available but can't
prepare it should fail and that should fail to probe the device.
That's exposing some kind of kernel or device bug that someone should
be fixing - exactly like you discovered here.

Jason