From: Fuad Tabba <fuad.tabba@linux.dev>
To: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org
Cc: Marc Zyngier <maz@kernel.org>, Oliver Upton <oupton@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Mark Brown <broonie@kernel.org>,
kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org,
Fuad Tabba <tabba@google.com>
Subject: [PATCH] arm64: Defer the GMID_EL1 read to {init,update}_cpu_features()
Date: Wed, 19 Aug 2026 15:25:58 +0100 [thread overview]
Message-ID: <20260819142558.1300100-1-fuad.tabba@linux.dev> (raw)
__cpuinfo_store_cpu() gates the GMID_EL1 read on the raw
ID_AA64PFR1_EL1, so it reads the register on MTE hardware even when the
kernel has disabled MTE (CONFIG_ARM64_MTE=n or arm64.nomte). KVM sets
HCR_EL2.TID5 in that case, which traps the read to EL2 and injects an
UNDEF:
Internal error: Oops - Undefined instruction: 0000000002000000 [#1]
pc : __cpuinfo_store_cpu+0xf4/0x264
Call trace:
__cpuinfo_store_cpu+0xf4/0x264 (P)
secondary_start_kernel+0xc8/0x1d0
__secondary_switched+0xc0/0xc4
Kernel panic - not syncing: Attempted to kill the idle task!
Only pKVM is affected, and only for a CPU onlined after KVM init: its
PSCI CPU_ON relay sets the host HCR before the CPU enters EL1, whereas
plain nVHE sets it at CPUHP_AP_KVM_ONLINE, after cpuinfo_store_cpu().
Defer the read to {init,update}_cpu_features() and gate it on the
sanitised ID register, as MPAM already does. system_supports_mte()
cannot serve as the gate, as update_cpu_features() also runs during
initial SMP bring-up, before smp_cpus_done() calls
setup_system_features(). The init path gains the CONFIG_ARM64_MTE test
the update path already had, leaving SYS_GMID_EL1 uninitialised when
MTE is compiled out, where its only other user (lib/mte.S) is not
built.
Fixes: f35abcbb8a084 ("KVM: arm64: Trap MTE access and discovery when MTE is disabled")
Cc: stable@vger.kernel.org
Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
---
arch/arm64/kernel/cpufeature.c | 19 ++++++++++++++++---
arch/arm64/kernel/cpuinfo.c | 8 +++++---
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 9a22df0c5120f..5120f6721b1e0 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1176,6 +1176,17 @@ static bool detect_ftr_has_mpam(void)
return id_aa64pfr0_mpam(pfr0) || id_aa64pfr1_mpamfrac(pfr1);
}
+/*
+ * Mirrors system_supports_mte(), which cannot be used before the capabilities
+ * are finalised. KVM sets HCR_EL2.TID5 when it is false, trapping GMID_EL1.
+ */
+static bool detect_has_mte(void)
+{
+ u64 pfr1 = read_sanitised_ftr_reg(SYS_ID_AA64PFR1_EL1);
+
+ return IS_ENABLED(CONFIG_ARM64_MTE) && id_aa64pfr1_mte(pfr1);
+}
+
void __init init_cpu_features(struct cpuinfo_arm64 *info)
{
/* Before we start using the tables, make sure it is sorted */
@@ -1228,8 +1239,10 @@ void __init init_cpu_features(struct cpuinfo_arm64 *info)
init_cpu_ftr_reg(SYS_MPAMIDR_EL1, info->reg_mpamidr);
}
- if (id_aa64pfr1_mte(info->reg_id_aa64pfr1))
+ if (detect_has_mte()) {
+ info->reg_gmid = read_cpuid(GMID_EL1);
init_cpu_ftr_reg(SYS_GMID_EL1, info->reg_gmid);
+ }
}
static void update_cpu_ftr_reg(struct arm64_ftr_reg *reg, u64 new)
@@ -1490,8 +1503,8 @@ void update_cpu_features(int cpu,
* they read/write depends on the GMID_EL1.BS field. Check that the
* value is the same on all CPUs.
*/
- if (IS_ENABLED(CONFIG_ARM64_MTE) &&
- id_aa64pfr1_mte(info->reg_id_aa64pfr1)) {
+ if (detect_has_mte()) {
+ info->reg_gmid = read_cpuid(GMID_EL1);
taint |= check_update_ftr_reg(SYS_GMID_EL1, cpu,
info->reg_gmid, boot->reg_gmid);
}
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.
+ */
+
/*
* info->reg_mpamidr deferred to {init,update}_cpu_features because we
* don't want to read it (and trigger a trap on buggy firmware) if
--
2.39.5
next reply other threads:[~2026-08-19 14:26 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-19 14:25 Fuad Tabba [this message]
2026-08-22 9:13 ` [PATCH] arm64: Defer the GMID_EL1 read to {init,update}_cpu_features() Marc Zyngier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260819142558.1300100-1-fuad.tabba@linux.dev \
--to=fuad.tabba@linux.dev \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox