From: Marc Zyngier <maz@kernel.org>
To: Vincent Donnefort <vdonnefort@google.com>
Cc: oliver.upton@linux.dev, joey.gouly@arm.com,
suzuki.poulose@arm.com, yuzenghui@huawei.com,
catalin.marinas@arm.com, will@kernel.org, qperret@google.com,
tabba@google.com, linux-arm-kernel@lists.infradead.org,
kvmarm@lists.linux.dev, kernel-team@android.com
Subject: Re: [PATCH] KVM: arm64: Fix ICV_DIR_EL1 trapping detection for pKVM
Date: Mon, 09 Mar 2026 17:33:46 +0000 [thread overview]
Message-ID: <86h5qo7vr9.wl-maz@kernel.org> (raw)
In-Reply-To: <20260309160450.2610295-1-vdonnefort@google.com>
On Mon, 09 Mar 2026 16:04:50 +0000,
Vincent Donnefort <vdonnefort@google.com> wrote:
>
> For non-VHE KVM, can_trap_icv_dir_el1() relies on a hyp-stub HVC to
> read the ICH_VTR_EL2 register. This isn't compatible with pKVM enabled
> devices which are failing late calls to verify_local_cpu_caps() when
> hotplugging a CPU.
>
> In verify_local_cpu_caps(), system_has_cap initialised before pKVM kills
> the hyp-stub is most likely set, while cpu_has_cap fails to probe the
> feature creates a capability conflict and prevents the CPU from going
> online.
>
> Add an HVC to get the ICH_VTR_EL2 register and use it in for ICV_DIR_EL1
> trapping detection.
>
> Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
>
> diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
> index a1ad12c72ebf..81bac8faec44 100644
> --- a/arch/arm64/include/asm/kvm_asm.h
> +++ b/arch/arm64/include/asm/kvm_asm.h
> @@ -81,6 +81,7 @@ enum __kvm_host_smccc_func {
> __KVM_HOST_SMCCC_FUNC___kvm_timer_set_cntvoff,
> __KVM_HOST_SMCCC_FUNC___vgic_v3_save_aprs,
> __KVM_HOST_SMCCC_FUNC___vgic_v3_restore_vmcr_aprs,
> + __KVM_HOST_SMCCC_FUNC___vgic_v3_get_ich_vtr_el2,
> __KVM_HOST_SMCCC_FUNC___pkvm_reserve_vm,
> __KVM_HOST_SMCCC_FUNC___pkvm_unreserve_vm,
> __KVM_HOST_SMCCC_FUNC___pkvm_init_vm,
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index c31f8e17732a..0bca57c1cbe0 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -2345,13 +2345,17 @@ static bool can_trap_icv_dir_el1(const struct arm64_cpu_capabilities *entry,
> !is_midr_in_range_list(has_vgic_v3))
> return false;
>
> - if (is_kernel_in_hyp_mode())
> + if (is_kernel_in_hyp_mode()) {
> res.a1 = read_sysreg_s(SYS_ICH_VTR_EL2);
> - else
> + } else if (system_capabilities_finalized() && is_protected_kvm_enabled()) {
> + arm_smccc_1_1_hvc(KVM_HOST_SMCCC_FUNC(__vgic_v3_get_ich_vtr_el2), &res);
> + if (res.a0 == SMCCC_RET_NOT_SUPPORTED)
> + return false;
> + } else {
> arm_smccc_1_1_hvc(HVC_GET_ICH_VTR_EL2, &res);
> -
> - if (res.a0 == HVC_STUB_ERR)
> - return false;
> + if (res.a0 == HVC_STUB_ERR)
> + return false;
> + }
>
> return res.a1 & ICH_VTR_EL2_TDS;
> }
> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> index e7790097db93..0432852228f9 100644
> --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> @@ -463,6 +463,11 @@ static void handle___vgic_v3_get_gic_config(struct kvm_cpu_context *host_ctxt)
> cpu_reg(host_ctxt, 1) = __vgic_v3_get_gic_config();
> }
>
> +static void handle___vgic_v3_get_ich_vtr_el2(struct kvm_cpu_context *host_ctxt)
> +{
> + cpu_reg(host_ctxt, 1) = read_sysreg_s(SYS_ICH_VTR_EL2);
> +}
> +
> static void handle___vgic_v3_init_lrs(struct kvm_cpu_context *host_ctxt)
> {
> __vgic_v3_init_lrs();
> @@ -622,6 +627,7 @@ static const hcall_t host_hcall[] = {
> HANDLE_FUNC(__kvm_timer_set_cntvoff),
> HANDLE_FUNC(__vgic_v3_save_aprs),
> HANDLE_FUNC(__vgic_v3_restore_vmcr_aprs),
> + HANDLE_FUNC(__vgic_v3_get_ich_vtr_el2),
> HANDLE_FUNC(__pkvm_reserve_vm),
> HANDLE_FUNC(__pkvm_unreserve_vm),
> HANDLE_FUNC(__pkvm_init_vm),
>
This looks incredibly complicated. Since pKVM forbids late onlining of
CPUs, you are absolutely sure that you have already seen the CPU being
hot-plugged on.
So it would make a lot more sense to just return the current value of
the property you are trying to re-evaluate: you know for sure it
cannot change under your feet.
I have quickly tested the following hack:
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index c31f8e17732a3..947ff71b3b66b 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -2345,6 +2345,9 @@ static bool can_trap_icv_dir_el1(const struct arm64_cpu_capabilities *entry,
!is_midr_in_range_list(has_vgic_v3))
return false;
+ if (system_capabilities_finalized() && is_protected_kvm_enabled())
+ return cpus_have_final_cap(ARM64_HAS_ICH_HCR_EL2_TDIR);
+
if (is_kernel_in_hyp_mode())
res.a1 = read_sysreg_s(SYS_ICH_VTR_EL2);
else
which works for me. Could you please give it a go?
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2026-03-09 17:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-09 16:04 [PATCH] KVM: arm64: Fix ICV_DIR_EL1 trapping detection for pKVM Vincent Donnefort
2026-03-09 17:33 ` Marc Zyngier [this message]
2026-03-09 18:07 ` Vincent Donnefort
2026-03-10 8:56 ` 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=86h5qo7vr9.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=joey.gouly@arm.com \
--cc=kernel-team@android.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=oliver.upton@linux.dev \
--cc=qperret@google.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.