Re: [PATCH v6 1/9] iommu/arm-smmu-v3: Handle ARM erratum for CONT under invalidation with SVA

[Jason Gunthorpe <jgg@nvidia.com>]

On Thu, Sep 17, 2026 at 10:24:08AM +0100, Mark Rutland wrote:
> Hi Jason,
> 
> Nit on terminology below.
> 
> On Wed, Sep 16, 2026 at 09:27:42PM -0300, Jason Gunthorpe wrote:
> > The erratum (MMU-700: #3777127, S3: #3673557) deals with under
> > invalidation of a CONT PTE grouping in the SMMU. The recommended work
> > around is to use a Range Invalidate (RIL) that spans the entire CONT. The
> > only user of CONT in the kernel right now is through SVA sharing a CPU
> > page table that contains a CONT created by the mm.
> 
> As someone familiar with VMSA, I've never seen "RIL" used to describe a
> range invalidate and I think using that in the code below is confusing.
> I *think* "RIL" has come from "SMMUv3.2-RIL", which is the SMMU feature
> for Range Invalidate *and* Level hint, where "RI" is Range Invalidate,
> and "L" is Level.

Yes,

drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h:#define IDR3_RIL                    (1 << 10)

Unfortunately I've noticed a couple of places like this where the SMMU
terminology and VMSA differ a little bit. In these cases we've
historically choosen the SMMU naming in the SMMU driver to be
consistent with its spec.. I've definately seen this gets confusing
when talking to people familiar with the CPU spec and IP.

I had guessed it ment "Rang InvaLidate", but you are right:

  RIL, bit [10]
       Range-based Invalidations and Level hint support for TLBI.
       The value of this field is an IMPLEMENTATION DEFINED choice of:

The driver also calls it ARM_SMMU_FEAT_RANGE_INV, but I thought
range_inv everwhere made some very long names.

> Can we please spell that out as "range invalidate" or "range op"
> (matching the arm64 architecture code) rather than "RIL"?
 
> That'll be easier to follow, especially as nothing in the code mentions
> what "RIL" means -- that's only mentioned in this commit message.

The whole series uses ril as a shorthand for IDR3_RIL, and the spec
often does the same:

[25:20] SCALE Range invalidation scale.
		  * See below for use of this field in range invalidation.
		  * When TG == 0b00 this field is RES0.
		  * If SMMU_IDR3.RIL == 0, this field is RES0.
                         ^^^^^^^^^^^

So I'm certainly sympathetic, but I don't know we should diverge the
driver from the language in it's own spec.

Do you have a recommendation for a suitable short name? It is
meaningful work to rename everything in this series.. Will?

Thanks,
Jason