Re: [PATCH v2] arm64: Defer the GMID_EL1 read to {init,update}_cpu_features()
Catalin Marinas <[email protected]>
| Newsgroups | dev.linux.lists.kvmarm,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On Mon, Aug 24, 2026 at 08:10:04AM +0100, Fuad Tabba wrote:
> diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
> index d50e2a9b066b3..c8967f185e3dd 100644
> --- a/arch/arm64/kernel/cpuinfo.c
> +++ b/arch/arm64/kernel/cpuinfo.c
> @@ -502,12 +502,14 @@ 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))
> - info->reg_gmid = read_cpuid(GMID_EL1);
> -
> if (id_aa64pfr0_32bit_el0(info->reg_id_aa64pfr0))
> __cpuinfo_store_cpu_32bit(&info->aarch32);
>
> + /*
> + * info->reg_gmid deferred to {init,update}_cpu_features because
> + * reading it traps to EL2 when MTE is disabled.
> + */
The only nit I have is that cpu_data[0] now won't have the GMID_EL1 set.
It doesn't matter as we don't expose it via c_show() or sysfs, rather
for consistency. We have this inconsistency already with mpamidr.
I guess we just need to call init_cpu_features() on the per-CPU data
before the assignment to boot_cpu_data. Something like (untested):
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index d50e2a9b066b..d22f3514ab8b 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -538,7 +538,7 @@ void __init cpuinfo_store_boot_cpu(void)
{
struct cpuinfo_arm64 *info = &per_cpu(cpu_data, 0);
__cpuinfo_store_cpu(info);
+ init_cpu_features(info);
boot_cpu_data = *info;
- init_cpu_features(&boot_cpu_data);
}
Either way:
Reviewed-by: Catalin Marinas <[email protected]>