Re: [PATCH] arm64: Defer the GMID_EL1 read to {init,update}_cpu_features()
Marc Zyngier <[email protected]>
| Newsgroups | dev.linux.lists.kvmarm,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On Wed, 19 Aug 2026 15:25:58 +0100, Fuad Tabba <[email protected]> wrote: > > __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 Is that for a CPU that has gone through a an offline/online cycle? Because otherwise, such a CPU wouldn't be able to boot at all (we have a strong requirement that pKVM sees all CPUs at boot time). If that's the case, some clarification would be good. Otherwise, some clarification is absolutely required! ;-) > 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. I'm starting to wonder whether having CPUs to go through a feature collection process during an offline/online cycle is a good idea. The data should still be there, and is not expected to change. Is it just that we don't have the correct tracking information? Thanks, M. -- Without deviation from the norm, progress is not possible.