Hi Alex,

On Wed, 29 Sep 2021 16:29:09 +0100,
Alexandru Elisei [off-list ref] wrote:

Hi Marc,

On 9/24/21 09:25, Marc Zyngier wrote:

quoted

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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel