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

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Apr 10, 2026 at 03:06:32PM -0700, Nicolin Chen wrote:
> 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?

That sounds right, with all the changes there should be no cache
flushing on the free path since it is now always flushed on detach, so
the arm_smmu_domain_inv() should be deleted here too.

> 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.

Yes, so the comment is:

 Notice that the arm_smmu_mm_arch_invalidate_secondary_tlbs() op can
 still be called/running at this point. Like the normal detach flow
 the RCU protected ASID may still experiance harmless invalidation.
 However unlike normal domains the SVA invalidation will continue
 into free until the mmu_notifier_put().

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

Yes, but the parallel thread is still possible even in free which is
unusual compared to normal domains where it is illegal to call
map/unmap concurrently with free.

Jason