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

[Mark Rutland <mark.rutland@arm.com>]

On Thu, Sep 17, 2026 at 02:44:42PM +0100, Will Deacon wrote:
> On Thu, Sep 17, 2026 at 10:16:01AM -0300, Jason Gunthorpe wrote:
> > On Thu, Sep 17, 2026 at 10:24:08AM +0100, Mark Rutland wrote:
> > > 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?
> 
> I think that using RANGE_INV / range_inv would be more consistent with
> the existing code, but IDR3_RIL should remain as-is because it maps
> directly to the spec.

Yep -- to be clear, I didn't mean to change the IDR3_RIL naming, which
matches the architectural naming of the SMMU_IDR3.RIL field.

My concern was that 'RIL' was being used to refer to a range invalidate
operation (e.g. "a RIL"), which doesn't match any existing terminology,
and is opaque to the reader.

Using RANGE_INV / range_inv, along with "a range op" or similar in prose
sounds good to me.

Mark.