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

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Aug 14, 2026 at 09:34:17AM -0300, Jason Gunthorpe wrote:

> I'm also wondering if we are even OK with this errata today? The
> current RIL algorithm also does not guarentee the split up RILs will
> cover every CONT. This will happen to be true if the input range has
> certain properties but I have no idea if the SVA path or even the
> proposed CONT iopgtable change guarentees that.

I've looked into this and it looks like the current RIL implementation
does not meet the requirement to solve the errata, and these days SVA
provides CONT entries from the mm.

The errata says the RIL command must cover the *entire* CONT group. I
read this text as meaning two contiguous RILs with a split that is
inside a CONT group is still vulnerable to this errata. Each CONT
group must be fully covered by at least one RIL.

So the algorithm we have today where we take the range and split it
into many RILs has nothing that prevents the RIL split from landing
inside a CONT. SVA is not guarenteed to produce ranges with an
alignment or size that make this algorithm happen to choose aligned
splits.

I've prepared an errata fix patch that detects the errata and triggers
a very simplified version of this single-RIL algorithm only for SVA
invalidations. That will fix today's kerenel, it is reasonably small
and can go to -stable.

I've adjusted this series on top of that to use the double-RIL version
with no over invalidation that Robin suggested for paging domains and
single-RIL with over invalidation for SVA domains. This also turned
out pretty good.

For the iommupt integration, and enabling CONT for the paging
domains.. Ugh.

It seems at least our Spark CPU has this errata and requires CONT
support to work in paging domains, or it runs into its own isochronous
HW problems. So the easy answer of disable CONT isn't desirable.

So.. what I've come up with is a little tweak that still allows the 4k
granule's 64K CONT to work without any over invalidation, so we can
turn it on by default. That is enough for spark to work. Everything
else stays with status quo of no CONT.

If someone has another smart idea now is the time..

Jason