[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 at 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 at 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.