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

Marc Zyngier maz at kernel.org
Wed Oct 21 06:25:52 PDT 2026


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)

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



More information about the linux-arm-kernel mailing list