Re: [PATCH v3] arm64: Don't read GMID_EL1 when MTE is disabled

Fuad Tabba <[email protected]>
Newsgroups org.infradead.lists.linux-arm-kernel,dev.linux.lists.kvmarm,org.kernel.vger.linux-kernel
Message-ID <CA+EHjTx93ERXZV1visdfBOGtH7wHff6TAoeJe+pNtikPrRp8Qw@mail.gmail.com>
On Tue, 25 Aug 2026 at 15:14, Will Deacon <[email protected]> wrote:
...

> > Agreed it's separate, but v3 applies the override without checking
> > that the CPU has MTE2, so id_aa64pfr1.mte=2 on a CPU without it reads
> > a GMID_EL1 that isn't there. On the boot CPU that's before the
> > override is sanitised. Should I check the raw register before applying
> > the override, until the clamp lands?
>
> At which point, why don't we bite the bullet and implement Suzuki's
> idea so that __read_sysreg_by_encoding() does what you want more generally?
>
> https://lore.kernel.org/all/[email protected]/

v4 will be two patches: Suzuki's clamp first, then the GMID_EL1 gate
on __read_sysreg_by_encoding().

>
> > > If you are worried about additional trapping of the MRS, we should go
> > > for Will's improvement to always read the cached values in
> > > __read_sysreg_by_encoding().
> >
> > Not worried :) __cpuinfo_store_cpu() has already read ID_AA64PFR1_EL1
> > a few lines up.
>
> But if you go with __read_sysreg_by_encoding() then you'd still be
> reading it (and trapping) twice, no?

It would, and I'm fine with that on a CPU bring-up path.

Stay tuned!
/fuad
>
> Will
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.