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

On 17-Aug-26 15:08, Andrew Cooper wrote:
> 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.)
Yes.

~Michal

> 
> 
> 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