From: Marc Zyngier <maz@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: Oliver Upton <oupton@kernel.org>,
Fuad Tabba <fuad.tabba@linux.dev>,
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>,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] KVM: arm64: Initialise TCR2_EL2 for nVHE mode
Date: Fri, 04 Sep 2026 08:32:04 +0100 [thread overview]
Message-ID: <86o6ed4gln.wl-maz@kernel.org> (raw)
In-Reply-To: <20260904-kvm-arm64-nvhe-pie-v1-1-29d59f245e6c@kernel.org>
On Fri, 04 Sep 2026 00:14:41 +0100,
Mark Brown <broonie@kernel.org> wrote:
>
> We currently only configure TCR2_EL2 in VHE mode, this is done in
> __finalise_el2 which only runs for VHE. While all systems with TCR2_EL2
> should have VHE support users may wish to run them in nVHE mode, for
> example in order to use protected VMs.
>
> Determine the value to load for TCR2_EL2 in C code in a similar manner to
> TCR_EL2, further patches will configure some bits in the register. When
> resetting back to the hypervisor stub clear all bits in the register in
> case something without support for TCR2_EL2 runs later.
>
> The only practical impact should be if we are started with a misconfigured
> TCR2_EL2.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
> arch/arm64/include/asm/kvm_asm.h | 1 +
> arch/arm64/kernel/asm-offsets.c | 1 +
> arch/arm64/kvm/arm.c | 5 ++++-
> arch/arm64/kvm/hyp/nvhe/hyp-init.S | 18 ++++++++++++++++--
> 4 files changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
> index e5b92ac09e69..eb796436d6eb 100644
> --- a/arch/arm64/include/asm/kvm_asm.h
> +++ b/arch/arm64/include/asm/kvm_asm.h
> @@ -208,6 +208,7 @@ extern void *__vhe_undefined_symbol;
> struct kvm_nvhe_init_params {
> unsigned long mair_el2;
> unsigned long tcr_el2;
> + unsigned long tcr2_el2;
> unsigned long tpidr_el2;
> unsigned long stack_hyp_va;
> unsigned long stack_pa;
> diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
> index 9c853ed3ceab..baffe58015d6 100644
> --- a/arch/arm64/kernel/asm-offsets.c
> +++ b/arch/arm64/kernel/asm-offsets.c
> @@ -118,6 +118,7 @@ int main(void)
> DEFINE(HOST_DATA_CONTEXT, offsetof(struct kvm_host_data, host_ctxt));
> DEFINE(NVHE_INIT_MAIR_EL2, offsetof(struct kvm_nvhe_init_params, mair_el2));
> DEFINE(NVHE_INIT_TCR_EL2, offsetof(struct kvm_nvhe_init_params, tcr_el2));
> + DEFINE(NVHE_INIT_TCR2_EL2, offsetof(struct kvm_nvhe_init_params, tcr2_el2));
> DEFINE(NVHE_INIT_TPIDR_EL2, offsetof(struct kvm_nvhe_init_params, tpidr_el2));
> DEFINE(NVHE_INIT_STACK_HYP_VA, offsetof(struct kvm_nvhe_init_params, stack_hyp_va));
> DEFINE(NVHE_INIT_PGD_PA, offsetof(struct kvm_nvhe_init_params, pgd_pa));
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 8b080804bc90..88eb0459ad4b 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -2158,7 +2158,7 @@ static int kvm_init_vector_slots(void)
> static void __init cpu_prepare_hyp_mode(int cpu, u32 hyp_va_bits)
> {
> struct kvm_nvhe_init_params *params = per_cpu_ptr_nvhe_sym(kvm_init_params, cpu);
> - unsigned long tcr;
> + unsigned long tcr, tcr2;
>
> /*
> * Calculate the raw per-cpu offset without a translation from the
> @@ -2186,6 +2186,9 @@ static void __init cpu_prepare_hyp_mode(int cpu, u32 hyp_va_bits)
> tcr |= TCR_T0SZ(hyp_va_bits);
> params->tcr_el2 = tcr;
>
> + tcr2 = 0;
> + params->tcr2_el2 = tcr2;
> +
> params->pgd_pa = kvm_mmu_get_httbr();
> if (is_protected_kvm_enabled())
> params->hcr_el2 = HCR_HOST_NVHE_PROTECTED_FLAGS;
> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
> index 0b3e0b28dfc7..a39de9c20d27 100644
> --- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
> +++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
> @@ -137,8 +137,13 @@ alternative_if ARM64_HAS_CNP
> alternative_else_nop_endif
> msr ttbr0_el2, x2
>
> - ldr x0, [x0, #NVHE_INIT_TCR_EL2]
> - msr tcr_el2, x0
> + ldr x1, [x0, #NVHE_INIT_TCR_EL2]
> + msr tcr_el2, x1
> +
> +alternative_if ARM64_HAS_TCR2
> + ldr x1, [x0, #NVHE_INIT_TCR2_EL2]
> + msr REG_TCR2_EL2, x1
> +alternative_else_nop_endif
>
> isb
>
> @@ -250,6 +255,15 @@ reset:
> mov_q x5, INIT_SCTLR_EL2_MMU_OFF
> pre_disable_mmu_workaround
> msr sctlr_el2, x5
> +
> +alternative_if ARM64_HAS_TCR2
> + /*
> + * Disable any features we enabled in case the next user doesn't
> + * have TCR2_EL2 support.
> + */
> + msr REG_TCR2_EL2, xzr
> +alternative_else_nop_endif
> +
I don't see the point of this. The MMU is off, and if the next piece
of SW can't correctly initialise the HW, that's its problem.
And with this hunk gone, the rest should be moved to the following
patch.
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2026-09-04 7:32 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-03 23:14 [PATCH 0/2] KVM: arm64: Enable S1PIE for nVHE and hVHE Mark Brown
2026-09-03 23:14 ` [PATCH 1/2] KVM: arm64: Initialise TCR2_EL2 for nVHE mode Mark Brown
2026-09-04 7:32 ` Marc Zyngier [this message]
2026-09-04 11:35 ` Mark Brown
2026-09-04 13:13 ` Marc Zyngier
2026-09-03 23:14 ` [PATCH 2/2] KVM: arm64: Enable S1PIE for nVHE and hVHE Mark Brown
2026-09-04 7:25 ` Marc Zyngier
2026-09-04 10:33 ` Mark Brown
2026-09-04 11:29 ` Will Deacon
2026-09-04 11:48 ` Mark Brown
2026-09-04 12:20 ` Fuad Tabba
2026-09-04 13:38 ` Mark Brown
2026-09-04 13:57 ` Marc Zyngier
2026-09-04 17:40 ` Mark Brown
2026-09-04 13:41 ` Will Deacon
2026-09-04 14:13 ` Alexandru Elisei
2026-09-04 13:23 ` Marc Zyngier
2026-09-04 13:53 ` Mark Brown
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=86o6ed4gln.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=broonie@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=seiden@linux.ibm.com \
--cc=suzuki.poulose@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox