Re: [RFC PATCH 3/3] iommu/arm-smmu-v3: Add support for hitless replace of S1 domains

[Samiullah Khawaja <skhawaja@google.com>]

On Fri, Oct 23, 2026 at 11:29:09AM -0300, Jason Gunthorpe wrote:
>On Fri, Oct 23, 2026 at 03:04:23PM +0100, Robin Murphy wrote:
>> On 23/10/2026 2:49 pm, Jason Gunthorpe wrote:
>> > On Fri, Oct 23, 2026 at 02:43:28PM +0100, Robin Murphy wrote:
>> > > > @@ -3664,8 +3726,8 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev,
>> > > >    		struct arm_smmu_cd target_cd;
>> > > >    		arm_smmu_make_s1_cd(&target_cd, master, smmu_domain);
>> > > > -		arm_smmu_write_cd_entry(master, IOMMU_NO_PASID, cdptr,
>> > > > -					&target_cd);
>> > > > +		arm_smmu_replace_cd_entry(master, IOMMU_NO_PASID, cdptr,
>> > > > +					  &target_cd);
>> > >
>> > > No, we cannot blindly do this for arbitrary ->attach_dev calls - the
>> > > majority of S1->S1 transitions are going to be moving back and forth between
>> > > the default domain and user domains, where there is zero expectation, let
>> > > alone guarantee, that the translations would be equivalent and thus not
>> > > liable to lead to TLB conflict aborts or amalgamation hell.
>> >
>> > Heh, yeah this probably only works properly with BBML2 or something so
>> > the temporary ASID doesn't explode.
>>
>> This is fundamental VMSA behaviour - see R_FVQCK in the Arm ARM. BBML only
>> applies to the one specific case of identical VA->PA translations with
>> identical attributes _only_ differing in the leaf level at which they are
>> described.

Thinking about this more, in case of a conflict, what is the expected
behaviour? Does it result in a DMA fault for the affected IOVA, or is it
a catastrophic event for the SMMU itself, affecting other devices and
the whole system?
>
>Sigh, I thought ARM got past that 'tlb conflicts catch fire'.
>
>So, yeah we need a flag that says "I pinky swear these are identical
>translations". And it has to be a kernel only flag since we can't let
>userspace trigger this.

Agreed, this should only be requestable through a kernel-only flag.
 From the live update side, we would set it only when replacing the
restored (preserved) domain with the new one, where the translations are
identical by construction, including the page sizes used.
>
>Jason

Thanks,
Sami