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