[PATCH v2 7/8] iommu/arm-smmu-v3: Change how the tlbi describes the invalidation
Jason Gunthorpe
jgg at nvidia.com
Mon Jul 6 12:45:47 PDT 2026
On Mon, Jul 06, 2026 at 07:00:15PM +0100, Robin Murphy wrote:
> On 2026-07-06 5:26 pm, Jason Gunthorpe wrote:
> [...]
> > /*
> > - * Generate a single range TLBI command covering [iova, iova+size). Sets
> > + * Compute the TTL hint from leaf/table level bitmaps. 0 ttlt means no hint
> > + * invalidate all levels.
> > + */
> > +static unsigned int arm_smmu_compute_ttl(u8 leaf_bitmap, u8 table_bitmap,
> > + unsigned int tg)
> > +{
> > + int ttl;
> > +
> > + if (leaf_bitmap) {
> > + if (is_power_of_2(leaf_bitmap))
> > + ttl = 3 - (int)__ffs(leaf_bitmap);
> > + else
> > + ttl = 0;
> > +
> > + if (table_bitmap) {
> > + int table_ttl = 3 - (int)__ffs(table_bitmap) + 1;
> > +
> > + /*
> > + * A RIL invalidation with !leaf_only clears out all
> > + * table levels above the leaf level ttl only.
> > + */
> > + if (table_ttl > ttl)
> > + ttl = 0;
> > + }
> > + } else if (table_bitmap) {
> > + ttl = 3 - (int)__ffs(table_bitmap) + 1;
>
> Maybe I'm misunderstanding what table_bitmap represents, but whichever way:
> - if this case means purely changes to table (i.e. non-leaf) PTEs
> themselves, then calculating any leaf level is pretty pointless.
Yeah, it means this.
RIL doesn't have a table-only mode, it always includes leaf
invalidation. So my reasoning is the best RIL to form has a TTL which
hints the fewest leaves, meaning the leaf level below the target
tables.
I guess 0/no-hint is the only other choice, do you think it is better?
FWIW, a future feature I've talked about to remove unused tables would
generate table only gathers, but currently it should be impossible.
> > + /* 16K granule, ARM TTL=1 is reserved (SMMUv3 F.b Section 4.4.1) */
> > + if (tg == 14 && ttl == 1)
> > + return 0;
>
> It's reserved in the absence of LPA2, i.e. when DS=0 (side note, please
> refer to an up-to-date version of the architecture - F.b is pretty old by
> now)
Oh, I see the note is ment to be read that TTL=0b01 is legal when DS=1
and works normally..
> VA. If between the caller and the code above we can calculate that a block
> entry exists where it cannot, then something is wrong and needs fixing
> properly.
Yes for leaves, but, the above is mixing tables into this as well, so
at this point there can be ttl's for any point in the tree except the
top most level, hence the check.
If table-only changes to use TTL=0 then this could be a WARN_ON to
detect malformed gathers.
> > + /* ARM levels -1 and 0 cannot be hinted */
> > + if (ttl <= 0 || ttl > 3)
> > + return 0;
>
> Similarly, no format allows blocks at level -1, so again if that check ever
> did anything we'd already have bigger problems. In the remaining case, 4KB
> with 52-bit VA *does* permit blocks at level 0, but it should hopefully be
> obvious why that doesn't need special treatment here either...
Yes, the -1 test can be WARN_ON as it is a malformed gather.
The 0 level is just a comment than it isn't actually a hint
anymore. I'll adjust them
Thanks,
Jason
More information about the linux-arm-kernel
mailing list