RE: [PATCH v2 4/7] iommu/arm-smmu-v3: Mark ATC invalidate timeouts via lockless bitmap

Tian, Kevin
2026-04-10T07:39:30Z

> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Tuesday, March 24, 2026 7:51 AM
>
> On Wed, Mar 18, 2026 at 08:12:04PM -0700, Nicolin Chen wrote:
> > > > VT-d is able to find out the SID of the device for which the device TLB
> > > > invalidation timed-out occured by using the SID reported in the
> > > > "Invalidation Queue Error Record Register" (VT-d Specs 11.4.9.9).
> > >
> > > yes. but when there are multiple submissions (each with a wait descriptor)
> > > fetched/handled by the hw and then an invalidation timeout comes, all
> > > pending wait descriptors will be aborted (not just the one corresponding
> > > to the timeout). In this case all affected submitters need to re-try.
> >
> > This sounds similar to SMMU then.
>
> Not entirely.. smmu HW stops processing at a SYNC and waits for
> everything pending to complete, then goes on forward. If there is a HW
> reported ATC timeout then it is contained to the SYNC that followed
> the ATC invalidation. The errored sync is skipped and whatever follows
> continues forward, so it doesn't contaminate future work.
>
> VT-d's wait descriptor with fence FN=1 sounds identical???

yes

>
> I guess if FN=0 then things start to become indeterminate what the
> wait actually waits for..
>

Currently we use FN=0, so all pending works before head pointer will be
re-submitted. It has a larger impact compared to FN=1 when a timeout
happens, but allows more parallel work in hardware at other times.