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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aFf5EYvF3NVr9MKm@linux.dev>
Date: Sun, 22 Jun 2025 05:37:37 -0700
From: Oliver Upton <oliver.upton@...ux.dev>
To: Marc Zyngier <maz@...nel.org>
Cc: Sascha Bischoff <Sascha.Bischoff@....com>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	"kvmarm@...ts.linux.dev" <kvmarm@...ts.linux.dev>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, nd <nd@....com>,
	Joey Gouly <Joey.Gouly@....com>,
	Suzuki Poulose <Suzuki.Poulose@....com>,
	"yuzenghui@...wei.com" <yuzenghui@...wei.com>,
	"will@...nel.org" <will@...nel.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"lpieralisi@...nel.org" <lpieralisi@...nel.org>,
	Timothy Hayes <Timothy.Hayes@....com>
Subject: Re: [PATCH 4/5] KVM: arm64: gic-v5: Support GICv3 compat

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