Re: [PATCH v3 2/6] ARM/sysctl: Expose the supported guest GIC modes in physinfo

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 17/08/2026 1:39 pm, Orzel, Michal wrote:
> On 16-Jul-26 16:11, Julian Vetter wrote:
>> diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c
>> index 32cab4feff..3b0edf4cec 100644
>> --- a/xen/arch/arm/sysctl.c
>> +++ b/xen/arch/arm/sysctl.c
>> @@ -21,6 +24,29 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
>>  
>>      pi->arch_capabilities |= MASK_INSR(sve_encode_vl(get_sys_vl_len()),
>>                                         XEN_SYSCTL_PHYSCAP_ARM_SVE_MASK);
>> +
>> +    /*
>> +     * The GIC version(s) we're happy creating guests with.  Right now for
>> +     * simplicity it is tied to the active hardware version, but this will
>> +     * cease to be the case if/when the compatbility modes are enabled.
> s/compatbility/compatibility/
>
> GICv3 may support GICv2 and we support libxl guest requesting GICv2 on a GICv3
> host. Why are we not exposing this information here?

Hmm.  That wasn't my reading of the logic at the time I wrote this.

Looking at it again, we probably should be advertising the result of
vgic_v2_hw.enabled alongside the main GIC version.  (Plus whatever
ifdefary is required to make this build.)


The domain create side is even more wonky. 
arch_sanitise_domain_config() takes the toolstack choice of vGIC
versions and asks whether the number of CPUs is compatible, but it's
midway through arch_domain_create() which first notices if the requested
vGIC version isn't compatible with hardware.

There really wants to be an __ro_after_init supported_vgic_versions
(name subject to improvement) which is filled in by the various GIC
initialisation routines, rather than a set of backbacks into disjoint
drivers.

~Andrew