[PATCH v1] KVM: arm64: pkvm: Clear GICv3 LRs in the hypervisor

[PATCH v1] KVM: arm64: pkvm: Clear GICv3 LRs in the hypervisor

[Vincent Donnefort]

The LR registers are architecturally UNKNOWN when the CPU boots or
resumes. However, in protected mode, only the used ones are reset.
During boot the HVC __vgic_v3_init_lrs() is never called because
vgic_present is only set in init_subsystems(), after cpu_hyp_init() was
called. Also, the PM notifier isn't registered for pKVM and the HVC
becomes unavailable after the host is deprivileged.

Let the hypervisor itself clear those registers on CPU_ON, resume and
before deprivileging the host.

Cc: stable@vger.kernel.org
Fixes: fa8c3d65538a ("KVM: arm64: Keep nVHE EL2 vector installed")
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
---
 arch/arm64/kvm/hyp/nvhe/hyp-main.c   | 3 +++
 arch/arm64/kvm/hyp/nvhe/psci-relay.c | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
index ac64a036b0a9..0e0ca29b224b 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
@@ -754,6 +754,9 @@ static void handle___pkvm_create_private_mapping(struct kvm_cpu_context *host_ct
 
 static void handle___pkvm_prot_finalize(struct kvm_cpu_context *host_ctxt)
 {
+	if (hyp_gicv3_nr_lr)
+		__vgic_v3_init_lrs();
+
 	cpu_reg(host_ctxt, 1) = __pkvm_prot_finalize();
 }
 
diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
index e20db999e328..a0e17e416bb5 100644
--- a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
+++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
@@ -213,6 +213,9 @@ 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);
 
+	if (hyp_gicv3_nr_lr)
+		__vgic_v3_init_lrs();
+
 	trace_hyp_exit(host_ctxt, HYP_REASON_PSCI);
 	__host_enter(host_ctxt);
 }

base-commit: c03c1a14507dfaf8b856c2608f9ac216021fc222
-- 
2.56.0.212.g129ede20d9-goog

Re: [PATCH v1] KVM: arm64: pkvm: Clear GICv3 LRs in the hypervisor

[Fuad Tabba]

Hi Vincent,

On Wed, 21 Oct 2026 12:00:00 +0100, Vincent Donnefort
<vdonnefort@google.com> wrote:
> The LR registers are architecturally UNKNOWN when the CPU boots or
> resumes. However, in protected mode, only the used ones are reset.
[...]
> Cc: stable@vger.kernel.org

Could you say in the commit message what happens to a guest when an LR
isn't cleared? It's what justifies the Cc: stable.

I tested it with QEMU modified to leave a chosen value in the top LR
at every CPU reset. Without the patch, the guest took a spurious
interrupt when that LR held a pending interrupt. When the LR had only
its EOI bit set, the EOI maintenance interrupt stayed asserted while
the guest ran, and the guest didn't print anything in 150s. With the
patch, neither happened.

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

Cheers,
/fuad

Re: [PATCH v1] KVM: arm64: pkvm: Clear GICv3 LRs in the hypervisor

[Marc Zyngier]

On Wed, 21 Oct 2026 12:00:00 +0100,
Vincent Donnefort <vdonnefort@google.com> wrote:
> 
> The LR registers are architecturally UNKNOWN when the CPU boots or
> resumes. However, in protected mode, only the used ones are reset.
> During boot the HVC __vgic_v3_init_lrs() is never called because
> vgic_present is only set in init_subsystems(), after cpu_hyp_init() was
> called.

Why don't you fix this rather than making the init even more
different?

> Also, the PM notifier isn't registered for pKVM and the HVC
> becomes unavailable after the host is deprivileged.

Sanitising the LRs on PSCI_ON is probably the right thing to do, but I
don't understand why resetting the LRs is out of reach from the host,
given that the host is fully in charge of the interrupt injection, and
therefore controls the LRs.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

Re: [PATCH v1] KVM: arm64: pkvm: Clear GICv3 LRs in the hypervisor

[Vincent Donnefort]

On Wed, Oct 21, 2026 at 01:22:28PM +0100, Marc Zyngier wrote:
> On Wed, 21 Oct 2026 12:00:00 +0100,
> Vincent Donnefort <vdonnefort@google.com> wrote:
> > 
> > The LR registers are architecturally UNKNOWN when the CPU boots or
> > resumes. However, in protected mode, only the used ones are reset.
> > During boot the HVC __vgic_v3_init_lrs() is never called because
> > vgic_present is only set in init_subsystems(), after cpu_hyp_init() was
> > called.
> 
> Why don't you fix this rather than making the init even more
> different?

Ack, I'll make a patch to fix that first.

> 
> > Also, the PM notifier isn't registered for pKVM and the HVC
> > becomes unavailable after the host is deprivileged.
> 
> Sanitising the LRs on PSCI_ON is probably the right thing to do, but I
> don't understand why resetting the LRs is out of reach from the host,
> given that the host is fully in charge of the interrupt injection, and
> therefore controls the LRs.

I suppose I could reinstantiate the pm callbacks for pkvm to at least reset the
LRs?

-- 
Vincent

> 
> Thanks,
> 
> 	M.
> 
> -- 
> Without deviation from the norm, progress is not possible.

Re: [PATCH v1] KVM: arm64: pkvm: Clear GICv3 LRs in the hypervisor

[Marc Zyngier]

On Wed, 21 Oct 2026 13:50:22 +0100,
Vincent Donnefort <vdonnefort@google.com> wrote:
> 
> On Wed, Oct 21, 2026 at 01:22:28PM +0100, Marc Zyngier wrote:
> > On Wed, 21 Oct 2026 12:00:00 +0100,
> > Vincent Donnefort <vdonnefort@google.com> wrote:
> > > 
> > > The LR registers are architecturally UNKNOWN when the CPU boots or
> > > resumes. However, in protected mode, only the used ones are reset.
> > > During boot the HVC __vgic_v3_init_lrs() is never called because
> > > vgic_present is only set in init_subsystems(), after cpu_hyp_init() was
> > > called.
> > 
> > Why don't you fix this rather than making the init even more
> > different?
> 
> Ack, I'll make a patch to fix that first.
> 
> > 
> > > Also, the PM notifier isn't registered for pKVM and the HVC
> > > becomes unavailable after the host is deprivileged.
> > 
> > Sanitising the LRs on PSCI_ON is probably the right thing to do, but I
> > don't understand why resetting the LRs is out of reach from the host,
> > given that the host is fully in charge of the interrupt injection, and
> > therefore controls the LRs.
> 
> I suppose I could reinstantiate the pm callbacks for pkvm to at least reset the
> LRs?

I think there are two different things:

- pKVM must not rely on the host resetting the LRs once it is
  deprivileged (that's the PSCI_ON case)

- pKVM must not prevent the host from resetting the LRs (that's the
  "mind your own business" case).

Both need addressing. If that means the LRs get reset twice because
pKVM inherits the PM callbacks, so be it.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

Re: [PATCH v1] KVM: arm64: pkvm: Clear GICv3 LRs in the hypervisor

[Vincent Donnefort]

On Wed, Oct 21, 2026 at 02:25:52PM +0100, Marc Zyngier wrote:
> On Wed, 21 Oct 2026 13:50:22 +0100,
> Vincent Donnefort <vdonnefort@google.com> wrote:
> > 
> > On Wed, Oct 21, 2026 at 01:22:28PM +0100, Marc Zyngier wrote:
> > > On Wed, 21 Oct 2026 12:00:00 +0100,
> > > Vincent Donnefort <vdonnefort@google.com> wrote:
> > > > 
> > > > The LR registers are architecturally UNKNOWN when the CPU boots or
> > > > resumes. However, in protected mode, only the used ones are reset.
> > > > During boot the HVC __vgic_v3_init_lrs() is never called because
> > > > vgic_present is only set in init_subsystems(), after cpu_hyp_init() was
> > > > called.
> > > 
> > > Why don't you fix this rather than making the init even more
> > > different?
> > 
> > Ack, I'll make a patch to fix that first.
> > 
> > > 
> > > > Also, the PM notifier isn't registered for pKVM and the HVC
> > > > becomes unavailable after the host is deprivileged.
> > > 
> > > Sanitising the LRs on PSCI_ON is probably the right thing to do, but I
> > > don't understand why resetting the LRs is out of reach from the host,
> > > given that the host is fully in charge of the interrupt injection, and
> > > therefore controls the LRs.
> > 
> > I suppose I could reinstantiate the pm callbacks for pkvm to at least reset the
> > LRs?
> 
> I think there are two different things:
> 
> - pKVM must not rely on the host resetting the LRs once it is
>   deprivileged (that's the PSCI_ON case)

Definitely not a hot path, but if we keep this one ^, isn't a shame of making
the host issue HVCs on CPU resume to reset the LRs if we know the hypervisor did
it anyway?

-- 
Vincent

> 
> - pKVM must not prevent the host from resetting the LRs (that's the
>   "mind your own business" case).
> 
> Both need addressing. If that means the LRs get reset twice because
> pKVM inherits the PM callbacks, so be it.
> 
> Thanks,
> 
> 	M.
> 
> -- 
> Without deviation from the norm, progress is not possible.

Re: [PATCH v1] KVM: arm64: pkvm: Clear GICv3 LRs in the hypervisor

[Marc Zyngier]

On Wed, 21 Oct 2026 16:14:21 +0100,
Vincent Donnefort <vdonnefort@google.com> wrote:
> 
> On Wed, Oct 21, 2026 at 02:25:52PM +0100, Marc Zyngier wrote:
> > On Wed, 21 Oct 2026 13:50:22 +0100,
> > Vincent Donnefort <vdonnefort@google.com> wrote:
> > > 
> > > On Wed, Oct 21, 2026 at 01:22:28PM +0100, Marc Zyngier wrote:
> > > > On Wed, 21 Oct 2026 12:00:00 +0100,
> > > > Vincent Donnefort <vdonnefort@google.com> wrote:
> > > > > 
> > > > > The LR registers are architecturally UNKNOWN when the CPU boots or
> > > > > resumes. However, in protected mode, only the used ones are reset.
> > > > > During boot the HVC __vgic_v3_init_lrs() is never called because
> > > > > vgic_present is only set in init_subsystems(), after cpu_hyp_init() was
> > > > > called.
> > > > 
> > > > Why don't you fix this rather than making the init even more
> > > > different?
> > > 
> > > Ack, I'll make a patch to fix that first.
> > > 
> > > > 
> > > > > Also, the PM notifier isn't registered for pKVM and the HVC
> > > > > becomes unavailable after the host is deprivileged.
> > > > 
> > > > Sanitising the LRs on PSCI_ON is probably the right thing to do, but I
> > > > don't understand why resetting the LRs is out of reach from the host,
> > > > given that the host is fully in charge of the interrupt injection, and
> > > > therefore controls the LRs.
> > > 
> > > I suppose I could reinstantiate the pm callbacks for pkvm to at least reset the
> > > LRs?
> > 
> > I think there are two different things:
> > 
> > - pKVM must not rely on the host resetting the LRs once it is
> >   deprivileged (that's the PSCI_ON case)
> 
> Definitely not a hot path, but if we keep this one ^, isn't a shame of making
> the host issue HVCs on CPU resume to reset the LRs if we know the hypervisor did
> it anyway?

The really annoying thing is that we have divergence between
hypervisor backends that make the code fragile and harder to
maintain. Specially as we add CCA to the mix.

So my approach to this is to stop messing with the host code. It
should do what it is notionally supposed to do, and the hypervisor
code can do its own stuff. You can always optimise away the reset on
PSCI_ON if you add some tracking.

Is it worth it? Absolutely not. But that's where the complexity should
go.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.