Re: [PATCH v2 7/8] iommu/arm-smmu-v3: Change how the tlbi describes the invalidation

[Nicolin Chen <nicolinc@nvidia.com>]

On Thu, Jul 09, 2026 at 03:25:59PM -0300, Jason Gunthorpe wrote:
> I wonder if this Claude was thinking about a kernel before
> 84b2baf427968c1 where this flow would have been as-described?

You are right! I applied the patches on 7.2-rc1, but somehow AI was
still relying on the old code. I had a some hard time to fully get
it..

> With the kernel today the arm_smmu_tlb_inv_walk() is supposed to clear
> out the walk cache before freeing the table entry and the gather is
> supposed to clear out the leaf entries themselves. 84b2baf427968c1
> changed things so we always have a second leaf-only gather that covers
> the entire unmap range, which also introduced the double invalidation.

IIUIC, for the "double invalidation", the driver currently flushes:
 1. tlb_flush_walk(iova, size=2M, granule=4K, leaf-only=false)
      // flush both walk cache and leaf entries
 2.iommu_iotlb_sync((iova, size=2M, granule=2M, leaf-only=true)
      // flush the 1st leaf entry only

> What I missed is that because of that commit gather->pgsize is no
> longer correct, it will be 2M even if __arm_lpae_free_pgtable()
> unmapped 4k leaves. So we will still miss leaf invalidation :\

This also makes sense to me.

> > > +	 * If leaf_levels_bitmap is 0 then this is a walk cache only
> > > +	 * invalidation.
> > [...]
> > > +	u8 leaf_levels_bitmap;
> > 
> > Or is that only to implement a walkcache-only invalidation, such
> > that the leaf entries will have separate invalidation call(s)?
> 
> That was the plan

I see the full picture now.

Thanks
Nicolin