Re: [PATCH v4 18/24] iommu/arm-smmu-v3: Introduce master->ats_broken flag

[Nicolin Chen <nicolinc@nvidia.com>]

On Fri, Jun 05, 2026 at 08:03:15PM -0300, Jason Gunthorpe wrote:
> On Fri, Jun 05, 2026 at 02:56:06PM -0700, Nicolin Chen wrote:
> > On Fri, Jun 05, 2026 at 04:42:59PM -0300, Jason Gunthorpe wrote:
> > > I don't see any of these options as appealing. We have to maintain a
> > > few key invariants, and I think it cannot be done without a way to
> > > find all the domains that are using the STE.
> > > 
> > > One way or another you have to be using the invs list rw locks to
> > > synchronize the EATS state changes.
> > > 
> > > It is okayish to be sloppy when turning EATS off, but when turning it
> > > back on we do need to cycle through every invs list and toggle its
> > > lock to ensure that the invalidations are synchronized before
> > > EATS=enable happens.
> > 
> > I think the core guarantees that "cycle through every invs list"
> > happens: a PCI reset calls reset_prepare() blocking all the RID
> > and PASID domains and removing ATS entries from every invs list,
> > and then calls reset_done() that re-attach RID/PASID domains so
> > freshly new ATS entries will be installed before EATS=enable.
> 
> I think this whole thing is so async and racy this is not something we
> can truely rely on. The driver is going to have to make sure it
> doesn't get turned on accidentally while the CD is still populated.

You mean the driver needs to ensure that the ATS entires in the
invs list would not be skipped when STE.EATS is enabled, right?

Otherwise, INV_TYPE_ATS_BROKEN + per-master domain list cannot
prevent a concurrent attach() from turning on STE.EATS either.

> > > Given you must have a way to go from STE -> master -> all invs lists
> > > I'm not sure either option really makes such a large difference.
> > > 
> > > If so then adjusting the invs to disable the ATS is pretty simple, run
> > > over the xarray and set them all off. Yes you could find the master
> > > through a SID lookup with some locking adjustment.
> > > > 
> > > > (1) Per-invs marker: INV_TYPE_ATS_BROKEN + master_domains
> > > >     disable_ats() in the timeout path walks master->master_domains
> > > >     and flips matching ATS invs entries to the BROKEN type.
> > > > 
> > > >   + invs walker is free (one case label in the existing type switch).
> > > >   + No lock or pointer deref in the invs walker.
> > > >   + No master pointer stored in invs; no lifetime concern.
> > > > 
> > > >   - disable_ats() walks every (master, domain) and marks each invs
> > > >     set; the list needs locking usable from atomic.
> > > 
> > > This doesn't seem so bad
> > 
> > Yea, the only thing is that the disable path has to deal with a
> > complexity from going through a per-device domain list. Maybe it
> > can reuse iommu_group->pasid_array by taking xa_lock?
> 
> Maybe the locking seems tricky as the locks might end up nesting in
> weird ways.

Oh, that's thoughtful.

> The streams rb tree and existing master domains linked list seems
> appealing if the locking can nest acceptably.

Yea, limiting the locking at the driver-level is more manageable. 

> > > > (3) Per-master flag + inv->master pointer (v4)
> > > >     invs entry carries a master pointer; the invs walker reads
> > > >     cur->master->ats_broken directly.
> > > > 
> > > >   + invs walker is one READ_ONCE through a cached pointer.
> > > >   + disable_ats is one WRITE_ONCE.
> > > >   + atc_inv_master early-skip via one READ_ONCE.
> > > >   + attach gate + post-attach re-check, same as (2).
> > > > 
> > > >   - invs holds a master ptr, so release_device must synchronize_rcu()
> > > >     before freeing the master to drain walkers under rcu_read_lock().
> > > >     We dropped this from v4 for that reason.
> > > 
> > > synchronize_rcu is not right because you have to have gone through the
> > > rwlock so there can be no readers.
> > 
> > Ah, I think you are right! When release_device() is invoked, the
> > device must be already in the release (blocked) domain. So there
> > should be no domain->invs in the system holding its ATS entries.
> > And the enable part would work as (2).
> > 
> > In this case, (3) seems the best? It's fast on every aspect.
> 
> I don't like it mainly because of the sketch enable side, and if we
> tighten that then you can just do 1 which doesn't have a perf impact..

I agree that per-master flag alone would be racy. So, for it to
work, it would need an extra spinlock. This v4 actually added a
pairing ats_broken_lock to fence arm_smmu_write_entry() in the
attach path, while the quarantine path is disabling STE.EATS and
setting the per-master flag. With that, the driver can ensure:
 - no race in STE.EATS update
 - consistency between STE.EATS and ATS entries in every invs

> But still, I'm not sure how all the asyncess and races will resolve in
> any of these cases.

Maybe we can try "INV_TYPE_ATS_BROKEN + per-master domain list"
first and see if Sashiko might identify some corner case.

Thanks
Nicolin