Hi Alex, On Wed, 29 Sep 2021 16:29:09 +0100, Alexandru Elisei <alexandru.elisei@xxxxxxx> 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. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
