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

[Alexandru Elisei]

Hi Marc,

On 9/29/21 17:04, Marc Zyngier wrote:
> 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.

Thank you for the clarification, the patch looks good to me:

Reviewed-by: Alexandru Elisei <alexandru.elisei at arm.com>

Thanks,

Alex

>
> Thanks,
>
> 	M.
>