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

[Will Deacon]

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.

If we can do that without churning the driver (looks like we can), then
it's probably worth it, but I wouldn't be keen on churning existing code
for things like this.

Will