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

[Baolu Lu <baolu.lu@linux.intel.com>]

On 7/14/26 02:50, Nicolin Chen wrote:
> 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.

Yes, fair enough. The locking constraints here are tight, so keeping
this logic inside the iommu driver makes things simpler.

> 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.

Thanks,
baolu