[PATCH v4 2/2] arm64: Don't read GMID_EL1 when MTE is disabled

[Will Deacon]

On Thu, Aug 27, 2026 at 01:56:35PM +0100, Will Deacon wrote:
> On Tue, Aug 25, 2026 at 05:42:19PM +0100, Fuad Tabba wrote:
> > diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
> > index d50e2a9b066b3..389fca84f106b 100644
> > --- a/arch/arm64/kernel/cpuinfo.c
> > +++ b/arch/arm64/kernel/cpuinfo.c
> > @@ -502,7 +502,7 @@ static void __cpuinfo_store_cpu(struct cpuinfo_arm64 *info)
> >  	info->reg_id_aa64smfr0 = read_cpuid(ID_AA64SMFR0_EL1);
> >  	info->reg_id_aa64fpfr0 = read_cpuid(ID_AA64FPFR0_EL1);
> >  
> > -	if (id_aa64pfr1_mte(info->reg_id_aa64pfr1))
> > +	if (gmid_el1_accessible())
> >  		info->reg_gmid = read_cpuid(GMID_EL1);
> 
> I'm not sure this is safe. For the boot CPU, __cpuinfo_store_cpu() is
> called before init_cpu_features(), so the arm64_ftr_regs[] array hasn't
> been sorted and we can't call get_arm64_ftr_reg() reliably. In fact, it
> doesn't even look like the overrides will have been processed.
> 
> So we're in a bit of a chicken-and-egg problem here. Perhaps we need an
> early (__init) function that can apply the override manually to the
> value read from hardware using arm64_ftr_safe_value(). You'll probably
> need something like my old hack [1] to avoid the bsearch though :/

Thinking about this for a few more minutes, perhaps the best option for
a quick fix would be to:

 - Internalise gmid_el1_accessible() in cpufeature.c and take cpuinfo *
   as a parameter

 - It could then refer directly to the ftr reg, along the lines of:

	val = arm64_ftr_safe_value(&ftr_id_aa64pfr1,
				   <value from id_aa64pfr1_override>,
				   <value from cpuinfo>);

 - Then check val before accessing the gmid.

Then we can fix all this properly in the future by moving the override
stuff earlier.

Will