Subject: Re: [PATCH v4 09/10] iommu/arm-smmu-v3: Remove ASID/VMID from arm_smmu_domain

From: Nicolin Chen <[email-masked]>
Date: Fri, 10 Apr 2026 15:06:32 -0700

On Thu, Apr 09, 2026 at 09:27:34PM -0300, Jason Gunthorpe wrote:
> On Thu, Mar 19, 2026 at 12:51:55PM -0700, Nicolin Chen wrote:
> > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> > index 846a278fa5469..0e48264ccd01b 100644
> > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> > @@ -300,14 +300,6 @@ static void arm_smmu_sva_domain_free(struct iommu_domain *domain)
> >  	 */
> >  	arm_smmu_domain_inv(smmu_domain);
> >  
> > -	/*
> > -	 * Notice that the arm_smmu_mm_arch_invalidate_secondary_tlbs op can
> > -	 * still be called/running at this point. We allow the ASID to be
> > -	 * reused, and if there is a race then it just suffers harmless
> > -	 * unnecessary invalidation.
> > -	 */
> > -	xa_erase(&arm_smmu_asid_xa, smmu_domain->cd.asid);
> > -
> 
> I don't think this artifact has disappeared so the comment should
> probably remain too. It has become slightly different because it is
> now running under RCU protections so it will clear alot faster.

By taking a closer look, I think either the arm_smmu_domain_inv call
above or any concurrent arm_smmu_mm_arch_invalidate_secondary_tlbs
call is a NOP now?

We reworked the ASID lifecycle, which now ends when the last device
detaches. So, ASID was free-ed in arm_smmu_iotlb_tag_free() that did
a per-ASID flush also.

So, when freeing the SVA domain here, the domain should have an empty
invalidation array and the HW cache is flushed as well, right?

Nicolin