[PATCH v2 0/4] KVM: arm64: pkvm: Fix missing reset of GICv3 LRs

[PATCH v2 0/4] KVM: arm64: pkvm: Fix missing reset of GICv3 LRs

[Vincent Donnefort]

The GICv3 List Registers (LRs) are architecturally UNKNOWN when a CPU
boots or wakes up from a low-power state. When pKVM is enabled,
__vgic_v3_init_lrs() is currently never called on boot, CPU hotplug, or
CPU PM resume.

Following Marc's comments on v1, instead of handling the LR reset purely
inside the pKVM hypervisor, this series fixes the host CPU init, hotplug,
and PM paths to properly reset the vGIC LRs even when pKVM keeps the EL2
installed. This removes a few calls to is_protected_kvm_enabled() making
the whole hypervisor init machinery more generic.

Since pKVM can't trust the a deprivileged host, keep the reset in the
CPU_ON/CPU_SUSPEND path.

Changelog:

v2:
  * Make the __vgic_v3_init_lrs HVC always available. (Marc)
  * Propagate __hyp_reset_vectors() error and remove
    is_protected_kvm_enabled() special-casing in the host CPU init/PM
    paths so the host resets the vGIC LRs. (Marc)

v1 (https://lore.kernel.org/all/20261021110000.508827-1-vdonnefort@google.com/)

Vincent Donnefort (4):
  KVM: arm64: Make __vgic_v3_init_lrs HVC always available
  KVM: arm64: pkvm: Fix missing reset of GICv3 LRs
  KVM: arm64: pkvm: Reset GICv3 LRs in the hypervisor
  KVM: arm64: pkvm: Avoid trapping on HVC_RESET_VECTORS

 arch/arm64/include/asm/kvm_asm.h     |  2 +-
 arch/arm64/include/asm/virt.h        |  2 +-
 arch/arm64/kvm/arm.c                 | 58 ++++++++++++++++------------
 arch/arm64/kvm/hyp/nvhe/hyp-main.c   |  5 ++-
 arch/arm64/kvm/hyp/nvhe/psci-relay.c |  4 ++
 5 files changed, 43 insertions(+), 28 deletions(-)


base-commit: c03c1a14507dfaf8b856c2608f9ac216021fc222
-- 
2.56.0.257.gf7497c7d27-goog

[PATCH v2 1/4] KVM: arm64: Make __vgic_v3_init_lrs HVC always available

[Vincent Donnefort]

The __vgic_v3_init_lrs hypercall only resets the vGIC LRs. Those
registers are expected to be 0 when the host is running. As a
consequence, it is completely safe to make it available at all times,
even when pKVM is enabled and the host was deprivileged.

Fixes: 057bed206f70 ("KVM: arm64: Disable privileged hypercalls after pKVM finalisation")
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
---
 arch/arm64/include/asm/kvm_asm.h   | 2 +-
 arch/arm64/kvm/hyp/nvhe/hyp-main.c | 5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index e5b92ac09e69..ca7e55d8eec3 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -60,7 +60,6 @@ enum __kvm_host_smccc_func {
 	__KVM_HOST_SMCCC_FUNC___pkvm_create_private_mapping,
 	__KVM_HOST_SMCCC_FUNC___pkvm_cpu_set_vector,
 	__KVM_HOST_SMCCC_FUNC___kvm_enable_ssbs,
-	__KVM_HOST_SMCCC_FUNC___vgic_v3_init_lrs,
 	__KVM_HOST_SMCCC_FUNC___vgic_v3_get_gic_config,
 
 	MARKER(__KVM_HOST_SMCCC_FUNC_MIN_PKVM),
@@ -85,6 +84,7 @@ enum __kvm_host_smccc_func {
 	__KVM_HOST_SMCCC_FUNC___tracing_reset,
 	__KVM_HOST_SMCCC_FUNC___tracing_enable_event,
 	__KVM_HOST_SMCCC_FUNC___tracing_write_event,
+	__KVM_HOST_SMCCC_FUNC___vgic_v3_init_lrs,
 	__KVM_HOST_SMCCC_FUNC___vgic_v3_save_aprs,
 	__KVM_HOST_SMCCC_FUNC___vgic_v3_restore_vmcr_aprs,
 	__KVM_HOST_SMCCC_FUNC___vgic_v5_save_apr,
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
index ac64a036b0a9..c1f0de3ec43f 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
@@ -627,7 +627,8 @@ static void handle___vgic_v3_get_gic_config(struct kvm_cpu_context *host_ctxt)
 
 static void handle___vgic_v3_init_lrs(struct kvm_cpu_context *host_ctxt)
 {
-	__vgic_v3_init_lrs();
+	if (hyp_gicv3_nr_lr)
+		__vgic_v3_init_lrs();
 }
 
 static void handle___vgic_v3_save_aprs(struct kvm_cpu_context *host_ctxt)
@@ -910,7 +911,6 @@ static const hcall_t host_hcall[] = {
 	HANDLE_FUNC(__pkvm_create_private_mapping),
 	HANDLE_FUNC(__pkvm_cpu_set_vector),
 	HANDLE_FUNC(__kvm_enable_ssbs),
-	HANDLE_FUNC(__vgic_v3_init_lrs),
 	HANDLE_FUNC(__vgic_v3_get_gic_config),
 	HANDLE_FUNC(__pkvm_prot_finalize),
 
@@ -931,6 +931,7 @@ static const hcall_t host_hcall[] = {
 	HANDLE_FUNC(__tracing_reset),
 	HANDLE_FUNC(__tracing_enable_event),
 	HANDLE_FUNC(__tracing_write_event),
+	HANDLE_FUNC(__vgic_v3_init_lrs),
 	HANDLE_FUNC(__vgic_v3_save_aprs),
 	HANDLE_FUNC(__vgic_v3_restore_vmcr_aprs),
 	HANDLE_FUNC(__vgic_v5_save_apr),
-- 
2.56.0.257.gf7497c7d27-goog

Re: [PATCH v2 1/4] KVM: arm64: Make __vgic_v3_init_lrs HVC always available

[Fuad Tabba]

Hi Vincent,

On Thu, 22 Oct 2026 15:00:45 +0100, Vincent Donnefort <vdonnefort@google.com> wrote:
> The __vgic_v3_init_lrs hypercall only resets the vGIC LRs. Those
> registers are expected to be 0 when the host is running. As a
> consequence, it is completely safe to make it available at all times,
> even when pKVM is enabled and the host was deprivileged.

Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev>
Tested-by: Fuad Tabba <fuad.tabba@linux.dev>

Cheers,
/fuad

[PATCH v2 2/4] KVM: arm64: pkvm: Fix missing reset of GICv3 LRs

[Vincent Donnefort]

The vGIC LRs are architecturally UNKNOWN when the CPU boots or resumes.
However, in protected mode, only the used ones are reset, because the
HVC __vgic_v3_init_lrs() is never called:

  * During boot, vgic_present is only set in init_subsystems(), after
    cpu_hyp_init() was called.

  * During CPU hotplug, kvm_arch_enable_virtualization_cpu() never calls
    it either because kvm_hyp_initialized is always set.

  * During CPU resume, no notifier is registered for pKVM.

First, return the error of __hyp_reset_vectors(). On an error, we know
the hypervisor doesn't allow a reset. Only re-init what the host has
access to, no matter the KVM configuration, which is the vGIC LRs.

Then, cpu_hyp_init() is only called from init_subsystems and
kvm_arch_enable_virtualization_cpu(). Remove the kvm_hyp_initialized
gate: when pKVM is enabled, the cpu_hyp_reset() will just return an
error while for other modes, we already know kvm_hyp_initialized is
false at this point.

Finally, enable the PM notifiers for pKVM, it is now safe to do so. It
will ensure the host properly configures the vGIC LRs regardless of the
KVM configuration.

Fixes: fa8c3d65538a ("KVM: arm64: Keep nVHE EL2 vector installed")
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
---
 arch/arm64/include/asm/virt.h |  2 +-
 arch/arm64/kvm/arm.c          | 51 +++++++++++++++++++----------------
 2 files changed, 29 insertions(+), 24 deletions(-)

diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
index b546703c3ab9..a5bde8cc5df5 100644
--- a/arch/arm64/include/asm/virt.h
+++ b/arch/arm64/include/asm/virt.h
@@ -83,7 +83,7 @@ extern u32 __boot_cpu_mode[2];
 #define ARM64_VECTOR_TABLE_LEN	SZ_2K
 
 void __hyp_set_vectors(phys_addr_t phys_vector_base);
-void __hyp_reset_vectors(void);
+int __hyp_reset_vectors(void);
 bool is_kvm_arm_initialised(void);
 
 DECLARE_STATIC_KEY_FALSE(kvm_protected_mode_initialized);
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 0576c2022ef5..4c4e2fb7b660 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -2246,10 +2246,12 @@ static void cpu_init_hyp_mode(void)
 	}
 }
 
-static void cpu_hyp_reset(void)
+static int cpu_hyp_reset(void)
 {
 	if (!is_kernel_in_hyp_mode())
-		__hyp_reset_vectors();
+		return __hyp_reset_vectors() ? -EPERM : 0;
+
+	return 0;
 }
 
 /*
@@ -2300,32 +2302,39 @@ static void cpu_hyp_init_features(void)
 		kvm_timer_init_vhe();
 		kvm_debug_init_vhe();
 	}
-
-	if (vgic_present)
-		kvm_vgic_init_cpu_hardware();
 }
 
 static void cpu_hyp_reinit(void)
 {
-	cpu_hyp_reset();
-	cpu_hyp_init_context();
-	cpu_hyp_init_features();
+	if (!cpu_hyp_reset()) {
+		cpu_hyp_init_context();
+		cpu_hyp_init_features();
+	} else {
+		if (WARN_ON(!__this_cpu_read(kvm_hyp_initialized)))
+			return;
+	}
+
+	/*
+	 * Even if the hypervisor didn't allow resetting the vectors we can
+	 * reset what we have access to.
+	 */
+	if (vgic_present)
+		kvm_vgic_init_cpu_hardware();
 }
 
 static void cpu_hyp_init(void *discard)
 {
-	if (!__this_cpu_read(kvm_hyp_initialized)) {
-		cpu_hyp_reinit();
-		__this_cpu_write(kvm_hyp_initialized, 1);
-	}
+	cpu_hyp_reinit();
+	__this_cpu_write(kvm_hyp_initialized, 1);
 }
 
 static void cpu_hyp_uninit(void *discard)
 {
-	if (!is_protected_kvm_enabled() && __this_cpu_read(kvm_hyp_initialized)) {
-		cpu_hyp_reset();
+	if (!__this_cpu_read(kvm_hyp_initialized))
+		return;
+
+	if (!cpu_hyp_reset())
 		__this_cpu_write(kvm_hyp_initialized, 0);
-	}
 }
 
 int kvm_arch_enable_virtualization_cpu(void)
@@ -2353,8 +2362,7 @@ void kvm_arch_disable_virtualization_cpu(void)
 	kvm_timer_cpu_down();
 	kvm_vgic_cpu_down();
 
-	if (!is_protected_kvm_enabled())
-		cpu_hyp_uninit(NULL);
+	cpu_hyp_uninit(NULL);
 }
 
 #ifdef CONFIG_CPU_PM
@@ -2397,13 +2405,11 @@ static struct notifier_block hyp_init_cpu_pm_nb = {
 
 static void __init hyp_cpu_pm_init(void)
 {
-	if (!is_protected_kvm_enabled())
-		cpu_pm_register_notifier(&hyp_init_cpu_pm_nb);
+	cpu_pm_register_notifier(&hyp_init_cpu_pm_nb);
 }
 static void __init hyp_cpu_pm_exit(void)
 {
-	if (!is_protected_kvm_enabled())
-		cpu_pm_unregister_notifier(&hyp_init_cpu_pm_nb);
+	cpu_pm_unregister_notifier(&hyp_init_cpu_pm_nb);
 }
 #else
 static inline void __init hyp_cpu_pm_init(void)
@@ -2526,8 +2532,7 @@ static int __init init_subsystems(void)
 	if (err)
 		hyp_cpu_pm_exit();
 
-	if (err || !is_protected_kvm_enabled())
-		on_each_cpu(cpu_hyp_uninit, NULL, 1);
+	on_each_cpu(cpu_hyp_uninit, NULL, 1);
 
 	return err;
 }
-- 
2.56.0.257.gf7497c7d27-goog

Re: [PATCH v2 2/4] KVM: arm64: pkvm: Fix missing reset of GICv3 LRs

[Fuad Tabba]

Hi Vincent,

On Thu, 22 Oct 2026 15:00:46 +0100, Vincent Donnefort <vdonnefort@google.com> wrote:
> The vGIC LRs are architecturally UNKNOWN when the CPU boots or resumes.
> However, in protected mode, only the used ones are reset, because the
> HVC __vgic_v3_init_lrs() is never called:

Could you say here what happens to a guest when an LR isn't reset, as I
asked on v1? Without this series, on QEMU changed to leave a pending
vINTID 100 in the top LR at CPU reset, the guest warns "Unexpected
interrupt (irqnr 100)". With only the EOI bit set there, the npVM
doesn't print anything in 150 seconds, since the maintenance interrupt
is asserted on every entry. With that in the message, could you also
bring back the Cc: stable you had on v1?

[...]
> Then, cpu_hyp_init() is only called from init_subsystems and
> kvm_arch_enable_virtualization_cpu(). Remove the kvm_hyp_initialized
> gate: when pKVM is enabled, the cpu_hyp_reset() will just return an
> error while for other modes, we already know kvm_hyp_initialized is
> false at this point.

In init_subsystems(), only the CPU that ran do_pkvm_init() returns an
error here. The others are still on the hyp stub, which returns 0 for
HVC_RESET_VECTORS, so they go through the full init. Could you reword
this part?

[...]
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
[...]
>  static void cpu_hyp_reinit(void)
>  {
> -        cpu_hyp_reset();
> -        cpu_hyp_init_context();
> -        cpu_hyp_init_features();
> +        if (!cpu_hyp_reset()) {
> +                cpu_hyp_init_context();
> +                cpu_hyp_init_features();
> +        } else {
> +                if (WARN_ON(!__this_cpu_read(kvm_hyp_initialized)))
> +                        return;
> +        }

Could you make this "} else if (WARN_ON(...)) {", as elsewhere in
arm.c?

> +
> +        /*
> +         * Even if the hypervisor didn't allow resetting the vectors we can
> +         * reset what we have access to.
> +         */

nit: "what we have access to" is the LRs, so I'd name them.

With the above addressed:
Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev>
Tested-by: Fuad Tabba <fuad.tabba@linux.dev>

Cheers,
/fuad

Re: [PATCH v2 2/4] KVM: arm64: pkvm: Fix missing reset of GICv3 LRs

[Vincent Donnefort]

On Thu, Oct 22, 2026 at 06:36:04PM +0100, Fuad Tabba wrote:
> Hi Vincent,
> 
> On Thu, 22 Oct 2026 15:00:46 +0100, Vincent Donnefort <vdonnefort@google.com> wrote:
> > The vGIC LRs are architecturally UNKNOWN when the CPU boots or resumes.
> > However, in protected mode, only the used ones are reset, because the
> > HVC __vgic_v3_init_lrs() is never called:
> 
> Could you say here what happens to a guest when an LR isn't reset, as I
> asked on v1? Without this series, on QEMU changed to leave a pending
> vINTID 100 in the top LR at CPU reset, the guest warns "Unexpected
> interrupt (irqnr 100)". With only the EOI bit set there, the npVM
> doesn't print anything in 150 seconds, since the maintenance interrupt
> is asserted on every entry. With that in the message, could you also
> bring back the Cc: stable you had on v1?

Sorry I missed that.

Actually I don't know if this should be backported. I believe it was working
until now because all SoCs do reset their LRs even though they don't have to do
it.

-- 
Vincent

> 
> [...]
> > Then, cpu_hyp_init() is only called from init_subsystems and
> > kvm_arch_enable_virtualization_cpu(). Remove the kvm_hyp_initialized
> > gate: when pKVM is enabled, the cpu_hyp_reset() will just return an
> > error while for other modes, we already know kvm_hyp_initialized is
> > false at this point.
> 
> In init_subsystems(), only the CPU that ran do_pkvm_init() returns an
> error here. The others are still on the hyp stub, which returns 0 for
> HVC_RESET_VECTORS, so they go through the full init. Could you reword
> this part?
> 
> [...]
> > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> [...]
> >  static void cpu_hyp_reinit(void)
> >  {
> > -        cpu_hyp_reset();
> > -        cpu_hyp_init_context();
> > -        cpu_hyp_init_features();
> > +        if (!cpu_hyp_reset()) {
> > +                cpu_hyp_init_context();
> > +                cpu_hyp_init_features();
> > +        } else {
> > +                if (WARN_ON(!__this_cpu_read(kvm_hyp_initialized)))
> > +                        return;
> > +        }
> 
> Could you make this "} else if (WARN_ON(...)) {", as elsewhere in
> arm.c?
> 
> > +
> > +        /*
> > +         * Even if the hypervisor didn't allow resetting the vectors we can
> > +         * reset what we have access to.
> > +         */
> 
> nit: "what we have access to" is the LRs, so I'd name them.
> 
> With the above addressed:
> Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev>
> Tested-by: Fuad Tabba <fuad.tabba@linux.dev>
> 
> Cheers,
> /fuad

Re: [PATCH v2 2/4] KVM: arm64: pkvm: Fix missing reset of GICv3 LRs

[Fuad Tabba]

On Fri, 23 Oct 2026 at 08:59, Vincent Donnefort <vdonnefort@google.com> wrote:
[..]
> > Could you say here what happens to a guest when an LR isn't reset, as I
> > asked on v1? Without this series, on QEMU changed to leave a pending
> > vINTID 100 in the top LR at CPU reset, the guest warns "Unexpected
> > interrupt (irqnr 100)". With only the EOI bit set there, the npVM
> > doesn't print anything in 150 seconds, since the maintenance interrupt
> > is asserted on every entry. With that in the message, could you also
> > bring back the Cc: stable you had on v1?
>
> Sorry I missed that.
>
> Actually I don't know if this should be backported. I believe it was working
> until now because all SoCs do reset their LRs even though they don't have to do
> it.

Fair enough, I'm fine with leaving the Cc: stable off.

Cheers,
/fuad

[PATCH v2 3/4] KVM: arm64: pkvm: Reset GICv3 LRs in the hypervisor

[Vincent Donnefort]

After the host is deprivileged, pKVM can't trust the host for resetting
the vGIC LRs whose value is architecturally UNKNOWN when the CPU boots
or resumes. Add a blanket cover in the CPU_ON/CPU_SUSPEND path.

Fixes: cdf367192766 ("KVM: arm64: Intercept host's CPU_ON SMCs")
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
---
 arch/arm64/kvm/hyp/nvhe/psci-relay.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
index e20db999e328..890ced64fb18 100644
--- a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
+++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
@@ -213,6 +213,10 @@ static void __noreturn __kvm_host_psci_cpu_entry(unsigned long pc, unsigned long
 	write_sysreg_el1(INIT_SCTLR_EL1_MMU_OFF, SYS_SCTLR);
 	write_sysreg(INIT_PSTATE_EL1, SPSR_EL2);
 
+	/* We can't trust the host to reset those registers */
+	if (hyp_gicv3_nr_lr)
+		__vgic_v3_init_lrs();
+
 	trace_hyp_exit(host_ctxt, HYP_REASON_PSCI);
 	__host_enter(host_ctxt);
 }
-- 
2.56.0.257.gf7497c7d27-goog

Re: [PATCH v2 3/4] KVM: arm64: pkvm: Reset GICv3 LRs in the hypervisor

[Fuad Tabba]

Hi Vincent,

On Thu, 22 Oct 2026 15:00:47 +0100, Vincent Donnefort <vdonnefort@google.com> wrote:
> After the host is deprivileged, pKVM can't trust the host for resetting
> the vGIC LRs whose value is architecturally UNKNOWN when the CPU boots
> or resumes. Add a blanket cover in the CPU_ON/CPU_SUSPEND path.
>
> Fixes: cdf367192766 ("KVM: arm64: Intercept host's CPU_ON SMCs")

Could you point this at 1025c8c0c6ac ("KVM: arm64: Wrap the host with a
stage 2") instead? The message relies on the host not being trusted, and
that starts there.

[...]
> diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
[...]
> @@ -213,6 +213,10 @@ static void __noreturn __kvm_host_psci_cpu_entry(unsigned long pc, unsigned long
>          write_sysreg_el1(INIT_SCTLR_EL1_MMU_OFF, SYS_SCTLR);
>          write_sysreg(INIT_PSTATE_EL1, SPSR_EL2);
>  
> +        /* We can't trust the host to reset those registers */

nit: "those registers" -> "the LRs".

With the Fixes: tag updated:
Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev>
Tested-by: Fuad Tabba <fuad.tabba@linux.dev>

Cheers,
/fuad

[PATCH v2 4/4] KVM: arm64: pkvm: Avoid trapping on HVC_RESET_VECTORS

[Vincent Donnefort]

pKVM prevents the reset of the hypervisor vector and as a consequence,
kvm_hyp_initialized can never be reset. Add a fast-path for this case to
skip unnecessary HVCs on the CPU hotplug and PM path.

Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
---
 arch/arm64/kvm/arm.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 4c4e2fb7b660..3d7199a87ca9 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -2248,8 +2248,13 @@ static void cpu_init_hyp_mode(void)
 
 static int cpu_hyp_reset(void)
 {
-	if (!is_kernel_in_hyp_mode())
+	if (!is_kernel_in_hyp_mode()) {
+		/* pKVM fast-path */
+		if (is_protected_kvm_enabled() && __this_cpu_read(kvm_hyp_initialized))
+			return -EPERM;
+
 		return __hyp_reset_vectors() ? -EPERM : 0;
+	}
 
 	return 0;
 }
-- 
2.56.0.257.gf7497c7d27-goog

Re: [PATCH v2 4/4] KVM: arm64: pkvm: Avoid trapping on HVC_RESET_VECTORS

[Fuad Tabba]

Hi Vincent,

On Thu, 22 Oct 2026 15:00:48 +0100, Vincent Donnefort <vdonnefort@google.com> wrote:
> pKVM prevents the reset of the hypervisor vector and as a consequence,
> kvm_hyp_initialized can never be reset. Add a fast-path for this case to
> skip unnecessary HVCs on the CPU hotplug and PM path.

Could you drop this patch? It brings back a pKVM check in the host code,
which Marc asked to avoid on v1 [1], to save one HVC that pKVM already
rejects.

Cheers,
/fuad

[1] https://lore.kernel.org/all/86jynbyshv.wl-maz@kernel.org/

Re: [PATCH v2 4/4] KVM: arm64: pkvm: Avoid trapping on HVC_RESET_VECTORS

[Vincent Donnefort]

On Thu, Oct 22, 2026 at 06:38:06PM +0100, Fuad Tabba wrote:
> Hi Vincent,
> 
> On Thu, 22 Oct 2026 15:00:48 +0100, Vincent Donnefort <vdonnefort@google.com> wrote:
> > pKVM prevents the reset of the hypervisor vector and as a consequence,
> > kvm_hyp_initialized can never be reset. Add a fast-path for this case to
> > skip unnecessary HVCs on the CPU hotplug and PM path.
> 
> Could you drop this patch? It brings back a pKVM check in the host code,
> which Marc asked to avoid on v1 [1], to save one HVC that pKVM already
> rejects.
> 
> Cheers,
> /fuad
> 
> [1] https://lore.kernel.org/all/86jynbyshv.wl-maz@kernel.org/

Exactly why I kept this patch separated :) 

It is a single documented fast-path while the series removed 5. 

But I agree this is only for the CPU resume or going out of idle path so not
really a hot path.

-- 
Vincent