From: Marc Zyngier <maz@kernel.org>
To: Fuad Tabba <fuad.tabba@linux.dev>
Cc: Oliver Upton <oupton@kernel.org>, Joey Gouly <joey.gouly@arm.com>,
Steffen Eiden <seiden@linux.ibm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Vincent Donnefort <vdonnefort@google.com>,
Quentin Perret <qperret@google.com>,
Fuad Tabba <tabba@google.com>,
kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] KVM: arm64: Track physical CPU number at EL2
Date: Mon, 19 Oct 2026 11:34:23 +0100 [thread overview]
Message-ID: <86y0buyo5s.wl-maz@kernel.org> (raw)
In-Reply-To: <20261014125510.2928306-2-fuad.tabba@linux.dev>
On Wed, 14 Oct 2026 13:55:09 +0100,
Fuad Tabba <fuad.tabba@linux.dev> wrote:
>
> The nVHE hypervisor has no equivalent of smp_processor_id(), so EL2 code
> has no index for the CPU it runs on.
>
> Add a hyp per-CPU hyp_cpu_number, which the host writes in
> cpu_prepare_hyp_mode() before it's deprivileged, and a
> hyp_smp_processor_id() accessor to read it. The next patch uses it to
> index per-CPU state in a hyp VM.
>
> Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
> ---
> arch/arm64/include/asm/kvm_hyp.h | 3 +++
> arch/arm64/kvm/arm.c | 3 +++
> arch/arm64/kvm/hyp/nvhe/hyp-smp.c | 2 ++
> 3 files changed, 8 insertions(+)
>
> diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h
> index b0e42be3d9eef..6c4169a14b73e 100644
> --- a/arch/arm64/include/asm/kvm_hyp.h
> +++ b/arch/arm64/include/asm/kvm_hyp.h
> @@ -16,6 +16,9 @@
> DECLARE_PER_CPU(struct kvm_cpu_context, kvm_hyp_ctxt);
> DECLARE_PER_CPU(unsigned long, kvm_hyp_vector);
> DECLARE_PER_CPU(struct kvm_nvhe_init_params, kvm_init_params);
> +DECLARE_PER_CPU(int, hyp_cpu_number);
> +
> +#define hyp_smp_processor_id() (__this_cpu_read(hyp_cpu_number))
>
Do we really need this? I was hoping that TPIDR_EL2 would give us a
way to compute the CPU number more or less directly, without having to
maintain per-CPU variable (which is pretty backward, when you think
about it...).
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2026-10-19 10:34 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-14 12:55 [PATCH 0/2] KVM: arm64: Per-vCPU TLB and I-cache flush in pKVM Fuad Tabba
2026-10-14 12:55 ` [PATCH 1/2] KVM: arm64: Track physical CPU number at EL2 Fuad Tabba
2026-10-19 10:34 ` Marc Zyngier [this message]
2026-10-19 11:43 ` Fuad Tabba
2026-10-14 12:55 ` [PATCH 2/2] KVM: arm64: Ensure TLBs and I-cache are private to each vCPU in pKVM Fuad Tabba
2026-10-14 15:53 ` Joey Gouly
2026-10-19 11:43 ` Fuad Tabba
2026-10-19 10:00 ` Vincent Donnefort
2026-10-19 11:43 ` Fuad Tabba
2026-10-19 12:39 ` Vincent Donnefort
2026-10-19 12:42 ` Vincent Donnefort
2026-10-19 12:45 ` Fuad Tabba
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=86y0buyo5s.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=fuad.tabba@linux.dev \
--cc=joey.gouly@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=oupton@kernel.org \
--cc=qperret@google.com \
--cc=seiden@linux.ibm.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=vdonnefort@google.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.com \
/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.