Re: [PATCH v2] arm64: Defer the GMID_EL1 read to {init,update}_cpu_features()

On Mon, 24 Aug 2026 at 16:54, Will Deacon <[email protected]> wrote:
>
> On Mon, Aug 24, 2026 at 04:14:41PM +0100, Fuad Tabba wrote:
> > On Mon, 24 Aug 2026 at 14:09, Will Deacon <[email protected]> wrote:
> >
> > > > +     /*
> > > > +      * info->reg_gmid deferred to {init,update}_cpu_features because
> > > > +      * reading it traps to EL2 when MTE is disabled.
> > > > +      */
> > >
> > > I don't think we should defer this, as I've been actively doing the
> > > opposite for parallel CPU onlining (where the ID registers can be read
> > > concurrently by incoming CPUs to amortise the cost of a trap) and also
> > > for the RNG traps during early boot:
> > >
> > > https://lore.kernel.org/all/annJ0oDB2HObQC5j@willie-the-truck/
> > >
> > > If you look at the diff I sent in the thread above (I didn't get a
> > > reply), the idea is that __read_sysreg_by_encoding() reads from the ID
> > > register values stashed by cpuinfo_store_cpu(). So you could use that
> > > to check id_aa64pfr1 before reading gmid, as it will give you the
> > > sanitised view.
> >
> > I just did, but I don't think it'll work. The thing is,
> > __read_sysreg_by_encoding() gives the override-applied local value,
> > not the folded sys_val.
> >
> > arm64.nomte is a command-line override, so that works. But
> > CONFIG_ARM64_MTE=n sets none. Any gate would still need an explicit
> > IS_ENABLED(CONFIG_ARM64_MTE).
> >
> > That said, I don't have to defer it. I can keep the info->reg_gmid
> > read in __cpuinfo_store_cpu() and gate that read on the state that
> > arms the trap:
> >
> >         static inline bool gmid_el1_accessible(u64 pfr1)
> >         {
> >                 if (!IS_ENABLED(CONFIG_ARM64_MTE))
> >                         return false;
> >                 if (system_capabilities_finalized())
> >                         return system_supports_mte();
> >                 return id_aa64pfr1_mte(pfr1);
> >         }
> >
> >
> > TID5 is set from system_supports_mte() and only once capabilities are
> > finalised, so the local check is still correct before that. Gating on
> > system_supports_mte() keeps the different-physical-CPU case you want
> > to preserve working: if one re-onlines with MTE while the system view
> > has it folded off, the gate stays false and it won't read GMID_EL1.
>
> I still don't understand why you have system_supports_mte() here. If
> the CPU has MTE, the CONFIG option is enabled and the cmdline override
> isn't set, we can read GMID just fine on this CPU, regardless of the
> system capabilities.

I could gate on the local value with the override applied instead.

> > If you agree, I'll respin with that.
>
> I can't tell who's calling gmid_el1_accessible() so it's hard to tell
> whether I agree or not. May as well send a v3 though, so we can see what
> you have in mind!

Sending it now. Probably shorter than just describing it.

Cheers,
/fuad

> Will