Re: [PATCH v5 18/18] iommu/arm-smmu-v3: Block ATS for a master upon an ATC invalidation timeout

[Nicolin Chen]

On Mon, Jul 13, 2026 at 08:20:29PM +0800, Baolu Lu wrote:
> My understanding of the sequence to quarantine a faulty ATS device is
> to:
> 
> 1. Identify the devices that encountered an ATC invalidation timeout
>    failure.
> 2. Have hardware block incoming DMA transfers and translation requests
>    by clearing the corresponding bits in the device's context/
>    translation table entries.
> 3. Have software prevent the driver from submitting new invalidation
>    requests or re-attaching a new domain to the device.
> 
> If this understanding is correct, then while steps 1 and 2 are hardware-
> and driver-specific, step 3 seems completely generic.

Step 3 is kinda driver-specific too for a few reasons:
a. This is in the iommu_unmap() context; called right before that
   function puts the kernel page. So, all the steps must be done
   before kernel reclaims the page (potentially to a new ATS for
   the same device whose ATC is stale).
b. Invalidation can be an IRQ context. So, can't use group->mutex,
   which a generic helper would likely need.
c. Given (a) and (b), extra driver-level spinlocks are required:
   streams_lock and master_domains_lock in this patch.
d. Step 3 actually has two small steps: disable ATS at the driver
   level; disable ATS entries in the invalidation array, either of
   which are currently driver-specific.

Jason has a view of moving the arm_smmu_invs to the core. So, maybe
step 3.2 (disabling it in the invalidation array) can be generic in
the future.

Nicolin