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

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:

quoted

+/* No ID register reflects CONFIG_ARM64_MTE. */
+static inline bool gmid_el1_accessible(void)
+{
+	if (!IS_ENABLED(CONFIG_ARM64_MTE))
+		return false;
+
+	return id_aa64pfr1_mte(__read_sysreg_by_encoding(SYS_ID_AA64PFR1_EL1));

I'm planning to internalise __read_sysreg_by_encoding() into cpufeature.c
so I'd prefer to avoid adding another user of it, if possible. In this case,
__cpuinfo_store_cpu() has already read the thing, so all it needs is the
override logic (but see below).

That's a valid point.

quoted

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

We no longer sort this array at boot-time, we just check that it's
pre-sorted.

In fact, it
doesn't even look like the overrides will have been processed.

init_feature_override() runs from early_map_kernel() but yes,
init_cpu_ftr_reg() hasn't been called yet to vet the override. Suzuki's
patch was adding extra checks in __read_sysreg_by_encoding() but if we
drop that patch (and function eventually), better not to rely on it.

So I don't think we have a correctness issue here but I don't mind v5
either. I'll go and check.

-- 
Catalin