All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Fuad Tabba <fuad.tabba@linux.dev>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.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: Re: [PATCH] arm64: Defer the GMID_EL1 read to {init,update}_cpu_features()
Date: Sat, 22 Aug 2026 10:13:17 +0100	[thread overview]
Message-ID: <86se464ixe.wl-maz@kernel.org> (raw)
In-Reply-To: <20260819142558.1300100-1-fuad.tabba@linux.dev>

On Wed, 19 Aug 2026 15:25:58 +0100,
Fuad Tabba <fuad.tabba@linux.dev> 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.

  reply	other threads:[~2026-08-22  9:13 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-19 14:25 [PATCH] arm64: Defer the GMID_EL1 read to {init,update}_cpu_features() Fuad Tabba
2026-08-22  9:13 ` Marc Zyngier [this message]
2026-08-23 13:09   ` Fuad Tabba
2026-08-24 13:11     ` Will Deacon

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=86se464ixe.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=fuad.tabba@linux.dev \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.