Re: [PATCH v3 5/5] KVM: arm64: GICv3: Force exit to sync ICH_HCR_EL2.En

[Marc Zyngier <maz@kernel.org>]

On Tue, 18 Nov 2025 07:16:49 +0000,
Oliver Upton <oupton@kernel.org> wrote:
> 
> Hey Marc,
> 
> On Mon, Nov 17, 2025 at 09:15:27AM +0000, Marc Zyngier wrote:
> > FEAT_NV2 is pretty terrible for anything that tries to enforce immediate
> > effects, and writing to ICH_HCR_EL2 in the hope to disable a maintenance
> > interrupt is vain. This only hits memory, and the guest hasn't cleared
> > anything -- the MI will fire.
> > 
> > For example, running the vgic_irq test under NV results in about 800
> > maintenance interrupts being actually handled by the L1 guest,
> > when none were expected.
> > 
> > As a cheap workaround, read back ICH_MISR_EL2 after writing 0 to
> > ICH_HCR_EL2. This is very cheap on real HW, and causes a trap to
> > the host in NV, giving it the opportunity to retire the pending
> > MI. With this, the above test tuns to completion without any MI
> > being actually handled.
> 
> Just to make sure I'm following, the scenario you're talking about is
> we've already put the vgic into a non-nested state, populated an LR with
> the pending MI at the time of that switch and L0 has no signal for when
> it can drop the LR / pending state.

Exactly. Only an exit can cause it to reevaluate the state and retire
the pending MI.

> 
> > Yes, this is really poor...
> 
> +1 :-/
> 
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> >  arch/arm64/kvm/hyp/vgic-v3-sr.c      | 7 +++++++
> >  arch/arm64/kvm/vgic/vgic-v3-nested.c | 6 ++++--
> >  2 files changed, 11 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm64/kvm/hyp/vgic-v3-sr.c b/arch/arm64/kvm/hyp/vgic-v3-sr.c
> > index 99342c13e1794..f503cf01ac82c 100644
> > --- a/arch/arm64/kvm/hyp/vgic-v3-sr.c
> > +++ b/arch/arm64/kvm/hyp/vgic-v3-sr.c
> > @@ -244,6 +244,13 @@ void __vgic_v3_save_state(struct vgic_v3_cpu_if *cpu_if)
> >  	}
> >  
> >  	write_gicreg(0, ICH_HCR_EL2);
> > +
> > +	/*
> > +	 * Hack alert: On NV, this results in a trap so that the above
> > +	 * write actually takes effect...
> > +	 */
> > +	isb();
> > +	read_gicreg(ICH_MISR_EL2);
> 
> I'm all for writing correct code but since we don't actually care about
> the value of MISR_EL2 do we need the ISB? There's no need for a CSE for
> non-NV and you'd get it 'for free' by way of exception entry in the NV
> case.

Yup, that's a good point. And exceptions are of course guaranteed to
be in program order anyway, so the ISB can go. I'll add comment to
that effect.

Thanks,

	M.

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