Re: [PATCH 4/5] KVM: arm64: gic-v5: Support GICv3 compat

[Oliver Upton <oliver.upton@linux.dev>]

On Sun, Jun 22, 2025 at 01:19:13PM +0100, Marc Zyngier wrote:
> On Fri, 20 Jun 2025 21:20:36 +0100,
> Oliver Upton <oliver.upton@linux.dev> wrote:
> > 
> > Hi Sascha,
> > 
> > Thank you for posting this. Very excited to see the GICv5 enablement get
> > started.
> > 
> > On Fri, Jun 20, 2025 at 04:07:51PM +0000, Sascha Bischoff wrote:
> > > Add support for GICv3 compat mode (FEAT_GCIE_LEGACY) which allows a
> > > GICv5 host to run GICv3-based VMs. This change enables the
> > > VHE/nVHE/hVHE/protected modes, but does not support nested
> > > virtualization.
> > 
> > Can't we just load the shadow state into the compat VGICv3? I'm worried
> > this has sharp edges on the UAPI side as well as users wanting to
> > migrate VMs to new hardware.
> >
> > The guest hypervisor should only see GICv3-only or GICv5-only, we can
> > pretend FEAT_GCIE_LEGACY never existed :)
> 
> That's exactly what this does. And the only reason NV isn't supported
> yet is the current BET0 spec makes ICC_SRE_EL2 UNDEF at EL1 with NV,
> which breaks NV in a spectacular way.

Gee, I wonder how... :)

> This will be addressed in a future revision of the architecture, and
> no HW will actually be built with this defect. As such, there is no
> UAPI to break.

That's fine by me. TBH, when I left this comment I hadn't fully read the
patch yet and was more curious about the intent.

> > > +void __vgic_v3_compat_mode_disable(void)
> > > +{
> > > +	sysreg_clear_set_s(SYS_ICH_VCTLR_EL2, ICH_VCTLR_EL2_V3, 0);
> > > +	isb();
> > > +}
> > > +
> > 
> > It isn't clear to me what these ISBs are synchonizing against. AFAICT,
> > the whole compat thing is always visible and we can restore the rest of
> > the VGICv3 context before guaranteeing the enable bit has been observed.
> 
> No, some registers have a behaviour that is dependent on the status of
> the V3 bit (ICH_VMCR_EL2 being one), so that synchronisation is
> absolutely needed before accessing this register.

Yeah, I had followed up on this after reading the spec, modal registers
are great. Putting all the constituent registers together in the common
load/put helpers will clear that up.

> The disabling is probably the wrong way around though, and I'd expect
> the clearing of V3 to have an ISB *before* the write to the sysreg,
> 
> > Can we consolidate this into a single hyp call along with
> > __vgic_v3_*_vmcr_aprs()?
> 
> I agree that we should be able to move this to be driven by
> load/put entirely.
> 
> But we first need to fix the whole WFI sequencing first, because this
> is a bit of a train wreck at the moment (entering the WFI emulation
> results in *two* "put" sequences on the vgic, and exiting WFI results
> in two loads).

You're talking about the case where halt polling fails and we do a
put/load on the whole vCPU to schedule right? i.e. in addition to the
explicit put on the vgic for faithful emulation.

Thanks,
Oliver