[PATCH v2 7/8] iommu/arm-smmu-v3: Change how the tlbi describes the invalidation
Nicolin Chen
nicolinc at nvidia.com
Thu Jul 9 14:32:19 PDT 2026
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
More information about the linux-arm-kernel
mailing list