[PATCH v7 8/9] iommu/arm-smmu-v3: Change how the tlbi describes the invalidation
Pranjal Shrivastava
praan at google.com
Mon Sep 28 11:25:34 PDT 2026
On Mon, Sep 21, 2026 at 08:55:16PM -0300, Jason Gunthorpe wrote:
> The range-invalidation logic has long had a FIXME that there is not enough
> information to properly compute the range invalidation. There is also
> subtly not enough information to properly compute the single stride
> either.
>
> Change tlbi to use the information format that iommupt is going to use for
> ARM. This prepares the invalidation code to support iommupt and fixes two
> small limitations with the current code.
>
> iommupt is designed to accumulate all invalidation into a single gather,
> then the iommu driver should issue a small number of commands to execute
> the gather to control invalidation latency. This is in contrast to
> io-pgtable-arm.c which generates many gather flushes and direct walk cache
> flushes as it progresses.
>
> To accommodate this the gather will accumulate "damage" in bitmaps, one
> for leaf changes and one for table changes. This is enough information for
> SMMUv3 to compute the proper stride for single invalidation and to
> generate ideal hints for range invalidation.
>
> Change the inner workings of the tlbi process to directly use this
> new-style gather description with the idea that the iommupt conversion
> will just direct assign the gather fields to the tlbi.
>
> Rework the three places creating the tlbi to express their needs in
> terms of the new bitmaps.
>
> 1) Simple iotlb invalidation always gets a single range of leaf
> levels, so it can set a single leaf bit
>
> 2) Walk invalidation is expected to clear the table and all the leaves it
> could contain. Set a single table bit and all the leaf bits.
>
> There is a weakness in the existing io-pgtable where it double
> invalidates the leaves, once through the arm_smmu_tlb_inv_walk() then
> again through the gather. Since these are separate operations they are
> not capped by the invalidation count limits and a single unmap may end
> up doing thousands of tlbi commands. Eventually converting to iommupt's
> gather only approach will correct this.
>
> 3) SVA invalidation has no idea what the MM did, so it will set all
> the bits in the bitmaps.
>
> This corrects another weakness where the range-invalidation logic
> was generating hints assuming the #2 rules which isn't correct
> for SVA.
>
> Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>
> Tested-by: Nicolin Chen <nicolinc at nvidia.com>
> Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
Reviewed-by: Pranjal Shrivastava <praan at google.com>
Thanks,
Praan
More information about the linux-arm-kernel
mailing list