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

On 7/14/26 02:50, Nicolin Chen wrote:

On Mon, Jul 13, 2026 at 08:20:29PM +0800, Baolu Lu wrote:

quoted

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