[RFC PATCH 0/3] iommu/arm-smmu-v3: Add support for hitless replace of CD entries
Robin Murphy
robin.murphy at arm.com
Fri Oct 23 07:12:56 PDT 2026
On 23/10/2026 2:46 pm, Jason Gunthorpe wrote:
> On Fri, Oct 23, 2026 at 01:10:56PM +0100, Robin Murphy wrote:
>> On 25/09/2026 2:13 am, Samiullah Khawaja wrote:
>>> This patch series adds support for replacing IOMMU domains with S1 page
>>> tables hitlessly, that is without disrupting the ongoing DMAs. This is
>>> one of the dependencies of the Liveupdate IOMMU support for Arm SMMUv3.
>>>
>>> S1 domains are programmed by CD entries in the CD table. During a new
>>> domain attach these are updated using arm_smmu_write_cd_entry(). Since
>>> ASID and TTB0 are in different 64-bit words, arm_smmu_write_cd_entry()
>>> considers it a non-hitless update and sets V=0. This means such an
>>> update is disruptive and would generate translation faults if there are
>>> ongoing DMAs.
>>>
>>> Replace the CD entries by using an unused temporary ASID in the
>>> following sequence to allow hitless replacement of CD entry,
>>>
>>> - Update the CD entry with temporary ASID.
>>> - Update the CD entry with the target TTB0.
>>> - Invalidate the temporary ASID.
>>> - Update the CD entry with target ASID.
>>> - Invalidate and release the temporary ASID.
>>
>> Why bother transitioning through a 3rd ASID? The old and new pagetables must
>> contain the same translations anyway, so why not just: switch ASID, switch
>> TTB, invalidate old ASID?
>
> The target ASID may be in use by another CD someplace else. Doing it
> without the temporary could contaminate it with wrong translations
> from the original TTB0.
>
> From a driver perspective we don't know why the domain replace
> operation was triggered. iommufd can trigger it for domains that are
> not identical. Corrupting the target ASID when we don't know for sure
> what is happening is not safe.
If there can be "wrong translations" then the whole thing is
fundamentally not safe to begin with.
> Obviously Samiullah's use case is hitless between the same translation
> so it doesn't need the extra ASID, but the driver can't know this.
Huh? If it doesn't need to be "hitless" then there is no need to do this
at all; break-before-make via an invalid CD is fine. If it does, then
the translations must be identical. Doesn't matter how many intermediate
ASIDs you go through, any time *one* of them could have fetched from two
different pagetables, you can't say for sure that an amalgamation of TLB
entries won't create something which ends up looking like a global
translation, that then "corrupts" *all* ASIDs.
Thanks,
Robin.
More information about the linux-arm-kernel
mailing list