Re: [PATCH v2 3/8] iommu/arm-smmu-v3: Optimize range invalidation for latency

[Nicolin Chen <nicolinc@nvidia.com>]

On Tue, Jul 07, 2026 at 04:13:29PM -0300, Jason Gunthorpe wrote:
> On Tue, Jul 07, 2026 at 12:27:00AM -0700, Nicolin Chen wrote:
> > On Mon, Jul 06, 2026 at 01:26:40PM -0300, Jason Gunthorpe wrote:
> > > +	/*
> > > +	 * There are at most 5 possible values for NUM based on SCALE. The
> > 
> > Mind elaborating the "at most 5 possible values for NUM"?
> 
> Oh, I guess it is at most 6 since it is +1

Yea, that's what I thought.

log2(NUM + 1) could be 5, 4, 3, 2, 1, or 0. So, totally 6.

> How about:
> 
> 	/*
> 	 * The spec defines the invalidated range as:
> 	 *   Range = ((NUM+1) * 2^SCALE) * Translation_Granule_Size
> 	 * NUM is 5 bits, so (NUM+1) covers 1..32 granules and SCALE scales
> 	 * that by a power of two. We must pick NUM and SCALE so the range
> 	 * covers num_tg granules, i.e. (NUM+1) * 2^SCALE >= num_tg with
> 	 * NUM+1 <= 32. That constrains SCALE to:
> 	 *    ceil(num_tg / 2^SCALE) <= 32
> 	 *    SCALE >= ceil(log2(num_tg / 32))
> 	 * Choosing the smallest such SCALE gives the finest granularity and
> 	 * thus the tightest (least over-covering) range, and equivalently the
> 	 * largest NUM.
> 	 *
> 	 * Unlike other IOMMUs the spec has no alignment requirement on the
> 	 * address beyond alignment to tg (so long as TTL=0).
> 	 */

This reads good to me.

With that,

Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>