[PATCH 1/5] KVM: arm64: Force ID_AA64PFR0_EL1.GIC=1 when exposing a virtual GICv3

[Marc Zyngier]

Hi Alex,

On Wed, 29 Sep 2021 16:29:09 +0100,
Alexandru Elisei <alexandru.elisei at arm.com> wrote:
> 
> Hi Marc,
> 
> On 9/24/21 09:25, Marc Zyngier wrote:
> > Until now, we always let ID_AA64PFR0_EL1.GIC reflect the value
> > visible on the host, even if we were running a GICv2-enabled VM
> > on a GICv3+compat host.
> >
> > That's fine, but we also now have the case of a host that does not
> > expose ID_AA64PFR0_EL1.GIC==1 despite having a vGIC. Yes, this is
> > confusing. Thank you M1.
> >
> > Let's go back to first principles and expose ID_AA64PFR0_EL1.GIC=1
> > when a GICv3 is exposed to the guest. This also hides a GICv4.1
> > CPU interface from the guest which has no business knowing about
> > the v4.1 extension.
> 
> Had a look at the gic-v3 driver, and as far as I can tell it does
> not check that a GICv3 is advertised in ID_AA64PFR0_EL1. If I didn't
> get this wrong, then this patch is to ensure architectural
> compliance for a guest even if the hardware is not necessarily
> compliant, right?

Indeed. Not having this made some of my own tests fail on M1 as they
rely on ID_AA64PFR0_EL1.GIC being correct. I also pondered setting it
to 0 when emulating a GICv2, but that'd be a change in behaviour, and
I want to think a bit more about the effects of that.

> 
> GICv4.1 is an extension to GICv4 (which itself was an extension to
> GICv3) to add support for virtualization features (virtual SGIs), so
> I don't see any harm in hiding it from the guest, since the guest
> cannot virtual SGIs.

Indeed. The guest already has another way to look into this by
checking whether the distributor allows active-less SGIs.

Thanks,

	M.

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