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