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

On Mon, Aug 24, 2026 at 04:14:41PM +0100, Fuad Tabba wrote:

Hi Will,

On Mon, 24 Aug 2026 at 14:09, Will Deacon [off-list ref] wrote:

quoted

quoted

+     /*
+      * 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/ (local)

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).

We need to revive this series:

https://lore.kernel.org/all/20260302115653.1517326-1-maz@kernel.org/ (local)

I don't remember where we left it but in principle config off or
override should look similar to the kernel.

There's also the override making an absent feature present. Suzuki has
attempted to fix this in a reply:

https://lore.kernel.org/all/afc5bd00-28ca-413b-b047-ee53589c285d@arm.com/ (local)

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 think this would be the easiest to backport and we can look at
reworking this infrastructure in the future (Will's proposal, Marc's
override fixes etc.)

-- 
Catalin