On Fri, Mar 06, 2026 at 10:01:15AM -0400, Jason Gunthorpe wrote:

On Fri, Mar 06, 2026 at 01:22:11PM +0000, Robin Murphy wrote:

quoted

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

quoted

On Thu, Mar 05, 2026 at 01:15:45PM -0800, Nicolin Chen wrote:

quoted

You mean in arm_smmu_cmdq_issue_cmdlist() that issued the timed
out ATC command?

Yes, it was my off hand thought.

quoted

So my test case was to trigger a device fault followed by an ATC
command. But, I found that the ATC command submission returned 0
while only the ISR received:
     CMDQ error (cons 0x03000003): ATC invalidate timeout
     arm_smmu_debugfs_atc_write: ATC_INV ret=0

It seems difficult to insert a CMDQ_OP_CFGI_STE in the submission
thread?

I didn't look, but I thought the CMDQ stops on the ATC invalidation,
flags the error and the ISR NOP's the failing CMDQ entry and restarts
it to resume the thread? Is that something else?

If so you could insert the STE flush instead of a NOP

Nope, sadly the timeout is asynchronous, and CERROR_ATC_INV_SYNC is only
reported on the *next* CMD_SYNC - it can't even tell us which CMD_ATC_INV(s)
had a problem.

!! That's a good point! The new invalidation code runs many ATC
invalidations under one sync to optimize for SVA performance so we
have no idea what devices need to be reset :(

So we really do need to signal to the issuing thread and it will have
to go back and check how many ATC invalidations are under this sync
and re-issue one by one to isolate the error then issue the STE change
and sync. Nothing from an ISR then..

IIUIC, we would have two timeouts to identify the device(s), so we
wouldn't need to give away the optimization of batching ATCI cmds?

Will letting a faulty device time out once again give it a window
to corrupt the memory?

Thanks
Nicolin