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

Robin Murphy robin.murphy at arm.com
Mon Jul 6 11:00:15 PDT 2026


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.
- conversely if it means to an invalidate an entire table worth of leaf 
PTEs at once, then L1 tables could contain a mix of both L2 and L3 
leaves, so a single level is not necessarily sufficient.
- at best, if it's the latter but you'd be generating separate 
invalidations for each individual sub-table from the bottom up, such 
that there would only be exactly one table_bitmap level per 
invalidation, isn't that pretty inefficient?

> +	} else {
> +		/* Both bitmaps zero is not allowed */
> +		return 0;
> +	}
> +
> +	/* 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) because the 16K format can only have L1 block entries when using 
52-bit 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.

> +	/* 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...

Thanks,
Robin.

> +	return ttl;
> +}



More information about the linux-arm-kernel mailing list