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

[Jason Gunthorpe]

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.

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.

Jason