Re: [PATCH v3 3/3] iommu/arm-smmu-v3: Fix ATS state tracking via ats_prepared gate

[Pranjal Shrivastava <praan@google.com>]

On Sat, May 23, 2026 at 09:34:18AM -0300, Jason Gunthorpe wrote:
> On Fri, May 22, 2026 at 04:14:01PM +0000, Pranjal Shrivastava wrote:
> > > 
> > > Though really pci_enable_ats is not working the way we want, writing
> > > the enable register can't actually fail - it is all the sanity
> > > checking for kernel bugs that is the problem here.
> > > 
> > > How about call pci_ats_supported() early in attach and fail, then if
> > > pci_enable_ats() fails just WARN_ON and keep going, kernel bug.
> > > 
> > > Re-organize pci_enable_ats() so it relies on pci_ats_supported() for
> > > all the sanity checks and cannot fail if supported is true.
> > 
> > Hmm, IIUC, the current situation says: 
> > 
> > pci_ats_supported ==> ATS cap check
> > pci_prepare_ats ==> ATS enablement prep 
> > 
> > Thus, I feel if the prepare fails, we should expect enable to fail. But
> > if prepare succeeds but enable didn't, that's the place we should
> > WARN_ON and move on.. because we (IOMMU) did the best we could have..
> > 
> > With the updated variants of pci_ats_support / pci_prepare_ats (in
> > patches 1 & 2), I believe we cover all the cases now..
> > 
> > And we plan to call prepare_ats only if (pci_ats_supported == true)
> > 
> > Thus, if prepare_ats failed, we fail at probe. And if probe succeeds but
> > enable ATS failed, that's something the IOMMU can't help with, hence we
> > WARN and move on? Does that sound good?
> 
> OK, what I really want to avoid is wrecking the attach flow. It is
> designed so the failable things happen early and after a certain point
> failure is no longer permitted, the enable_ats is after the point.
> 
> So it should continue to be structued like that - enable_ats
> failing is a kernel bug because earlier checks preclude it..

Ack. I see your point about maintaining the integrity of the attach flow
Will post another version

Thanks,
Praan