Re: [PATCH v2 2/4] arm64: tlb: Add tlbi workaround for FUJITSU-MONAKA Erratum E#030001

[Marc Zyngier <maz@kernel.org>]

On Fri, 16 Oct 2026 12:50:17 +0100,
Mark Rutland <mark.rutland@arm.com> wrote:
> 
> On Fri, Oct 16, 2026 at 07:00:46PM +0900, Tomohiro Misono wrote:
> > FUJITSU-MONAKA Erratum E#030001 affects FUJITSU-MONAKA CPU
> > when using TLBI range operations.
> > 
> > On affected FUJITSU-MONAKA CPUs, range-based TLBI operations
> > targeting a VA or IPA may fail to invalidate TLB entries when
> > addr[34:29] == all 1 && addr[28:0] == 0 for 512MB mappings.
> > The affected instructions are:
> >   RVA[L]E{1,2,3}*, RVAA[L]E1*, and RIPAS2[L]E1*.
> > 
> > Work around the erratum by issuing additional non-range
> > TLBI instructions corresponding to the affected VA or IPA
> > range-based TLBI operations.
> > 
> > Signed-off-by: Tomohiro Misono <misono.tomohiro@fujitsu.com>
> 
> As Will and I suggested last time, we'd prefer to disable range
> operations on these parts (and ensure that the relevant ID field is
> hidden from KVM guests).
> 
> Regardless of whether eventually accept the approach you propose here,
> we first need something simple to backport to stable trees (as I assume
> you'll want to run standard Linux distributions on this hardware). The
> TLB invalidation code has changed a lot over time, and I don't think
> it's practical or sensible to backport this patch.
> 
> As a first step, I think we should simply disable the use of range
> operations on these parts, and ensure that KVM hides the relevant ID
> field. After that, we can consider optimizing the workaround, as you
> propose here.
> 
> Marc, does that align with your expectations?

Yes. I'd rather we start with a clean slate so that an unsuspecting
guest cannot get things wrong because it doesn't know about the
erratum. Anything else is icing on the cake that is not desirable at
this stage.

> Is there an existing pattern to follow for hiding the ID field?

Ideally, TLBI_RANGE would be removed from the ID_AA64ISAR0_EL1 copy
that the kernel has, and KVM would simply inherit this. I'm not sure
we have a good way to do that other than doing horrible things with
the override masks.

Otherwise, something as simple as forcing the ID_AA64ISAR0_EL1 reset
value in sys_regs.c would work.

	M.

-- 
Without deviation from the norm, progress is not possible.