Re: [PATCH rc] iommu/arm-smmu-v3: Drain in-flight fault handlers

[Jason Gunthorpe]

On Tue, Mar 24, 2026 at 02:04:03PM +0000, Will Deacon wrote:
> Sorry, that was sloppy terminology on my part. I'm trying to reason about
> faults that are generated by accesses that were translated with the
> page-tables of the old domain being reported once we think we are using
> the new domain.

It doesn't matter.

If a concurrent fault is resolving on the old domain and it completes
after the STE is in the new domain the device will restart and if the
IOVA is still non-present it will refault. This is normal and fine.

If it is resolving on the new domain and the new domain has a present
PTE so the PRI is spurious then the fault handler should NOP it and
restart the device.

> > The ordering is supposed to be
> >  1) IOMMU HW starts using the new domain
> >  2) iommu_attach_handle_get() returns the new domain
> >  3) IOMMU driver flushes its own IRQs/queues that may be concurrently
> >     calling iommu_attach_handle_get()
> 
> Does that mean we should kick the evtq thread? I'm not sure what this
> means for the priq.

The locking issue is around iommu_attach_handle_get(), so any
thread/irq concurrently calling that has to be fenced. That's it. We
don't have to expedite or synchronize with concurrent PRI at all.

> I don't think we can rely on the IRQ being taken, though, so presumably
> we have to kick the irq thread manually and see what's actually sitting
> in the event queue after the CMD_SYNC?

Er, I thought the iommu_attach_handle_get() was in a threaded irq? If
it is in a WQ then yeah more is needed.

Jason