Re: [PATCH v1 2/2] iommu/arm-smmu-v3: Recover ATC invalidate timeouts

On Fri, Mar 06, 2026 at 11:56:46AM -0400, Jason Gunthorpe wrote:

On Fri, Mar 06, 2026 at 03:24:20PM +0000, Robin Murphy wrote:

quoted

On 2026-03-05 11:52 pm, Jason Gunthorpe wrote:

quoted

On Thu, Mar 05, 2026 at 01:06:21PM -0800, Nicolin Chen wrote:

quoted

That sounds like the IOPF implementation. Maybe inventing another
IOMMU_FAULT_ATC_TIMEOUT to reuse the existing infrastructure would
make things cleaner.

I think the routing is quite different, IOPF wants to route an event
the domain creator, here you want to route an event to the IOMMU core
then the PCIe RAS callbacks.

IDK if there is much to be reused there, especially since IOPF
requires a memory allocation and ideally we should not be allocating
memory to resolve this critical error condition.

Yeah, sorry, for a moment there I somehow forgot that we can expect to use
ATS without PRI, so indeed tying this to IOPF wouldn't be appropriate. And
given the general difficulty of trying to infer what went wrong and what to
do from the CMDQ contents alone, I do like your idea of trying to return a
new kind of sync failure back to arm_smmu_atc_inv_{master,domain}() so that
we can take any defensive action from there, with all the information to
hand. We'd just have to ensure that if a large set of ATCI commands needs to
span multiple batches, every batch must contain its own sync (since if some
other batch of unrelated commands could get interleaved in the middle and
issue a sync that then fails due to someone else's ATC timeout, everything's
likely to get confused and go wrong).

Yeah, that all makes sense to me.

The batching issue is scary, we definately can't allow an ATC
invalidation to be pushed without a SYNC that localizes any failure to
this specific thread, or we can't properly disambiguate the failures
anymore.

My feeling is when the sync "fails", it can bubble up the error and we
can get back to the invalidation list processor which can then see it
failed to process an ATC batch and take an appropriate action.

+1 just saw this thread (replied something similar)

quoted

The fiddly thing then is that we might also have to be prepared to "handle"
CMD_SYNC timeout by manually checking for GERRORs, in case the whole
invalidation is in the context of an dma_unmap within some other device's
IRQ handler, which happens to be on the same CPU where the GERROR IRQ is now
pending, but can't be taken until we can complete the inv and return out of
the current IRQ :/

IIRC didn't the PM patches propose to add this anyhow?

If this is regarding the runtime pm patches, I've tried to address the
Gerror issue (pointed out by you in v4) in the v5 [1]

Thanks,
Praan

[1] https://lore.kernel.org/all/20260126151157.3418145-9-praan@google.com/ (local)