When creating a domain on ARM, and passing XEN_DOMCTL_CONFIG_GIC_NATIVE
for the gic_version field in the struct xen_arch_domainconfig,
arch_sanitise_domain_config() resolves this to the approrpiate GIC_V2 or
GIC_V3 version the domain actually has, based on the host's
gic_hw_version(). That value is stored in the domain as
d->arch.vgic.version, but can't be queried through any other domctl
later. Toolstacks that create and build a domain in the same call
already have this info from the createdomain reply and never need to ask
again.

Toolstacks that create a domain and build it later from a separate
process do need to ask again. But, the ARM implementation only fills in
info->flags and info->gpaddr_bits. info->arch_config is left zeroed, so
XEN_DOMCTL_getdomaininfo always reports gic_version as
XEN_DOMCTL_CONFIG_GIC_NATIVE (0) regardless of what was actually
configured earlier.

Signed-off-by: Julian Vetter <julian.vetter@vates.tech>
---
 xen/arch/arm/domctl.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index 6c9a3f9920..b76af56fad 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -24,6 +24,8 @@ void arch_get_domain_info(const struct domain *d,
     info->flags |= XEN_DOMINF_hap;
 
     info->gpaddr_bits = p2m_ipa_bits;
+
+    info->arch_config.gic_version = d->arch.vgic.version;
 }
 
 static int handle_vuart_init(struct domain *d, 
-- 
2.53.0



-- 
 | Vates 

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

On 09/07/2026 2:20 pm, Julian Vetter wrote:
> When creating a domain on ARM, and passing XEN_DOMCTL_CONFIG_GIC_NATIVE
> for the gic_version field in the struct xen_arch_domainconfig,
> arch_sanitise_domain_config() resolves this to the approrpiate GIC_V2 or
> GIC_V3 version the domain actually has, based on the host's
> gic_hw_version(). That value is stored in the domain as
> d->arch.vgic.version, but can't be queried through any other domctl
> later. Toolstacks that create and build a domain in the same call
> already have this info from the createdomain reply and never need to ask
> again.
>
> Toolstacks that create a domain and build it later from a separate
> process do need to ask again. But, the ARM implementation only fills in
> info->flags and info->gpaddr_bits. info->arch_config is left zeroed, so
> XEN_DOMCTL_getdomaininfo always reports gic_version as
> XEN_DOMCTL_CONFIG_GIC_NATIVE (0) regardless of what was actually
> configured earlier.
>
> Signed-off-by: Julian Vetter <julian.vetter@vates.tech>
> ---
>  xen/arch/arm/domctl.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
> index 6c9a3f9920..b76af56fad 100644
> --- a/xen/arch/arm/domctl.c
> +++ b/xen/arch/arm/domctl.c
> @@ -24,6 +24,8 @@ void arch_get_domain_info(const struct domain *d,
>      info->flags |= XEN_DOMINF_hap;
>  
>      info->gpaddr_bits = p2m_ipa_bits;
> +
> +    info->arch_config.gic_version = d->arch.vgic.version;
>  }
>  
>  static int handle_vuart_init(struct domain *d, 

Huh, that's one bug I hadn't found in this mess.  I'm sorry to say that
this is tied up in a bigger set of issues.

The use of xen_arch_domainconfig for output has lead to two bogus
things; gic_version as you've found, and clock_frequency which is an
out-only parameter of a system-wide property.

This is horrible API abuse and is one of many things interfering with
the API/ABI cleanup/rework.

* System properties should be reported by SYSCTL phyinfo, not as an
output from DOMCTL createdomain.  This includes the available GIC
versions, and clock frequency.

* GIC_NATIVE is a wrong thing to have in the API.  Libxl should choose
the first available of (gic-v3, gic-v2), and Xen should only care that
the chosen option is compatible with the system.

* With the fields now moved into the correct hypercalls, config needs
making const through arch_sanitise_domain_config() so these kinds of
issues can't easily repeat.

I started this work with
https://gitlab.com/xen-project/hardware/xen-staging/-/commits/andrew/fix-arm-domcreate
but haven't had time to complete it.  If you'd like to tackle the others
while you're at it, I'd be very grateful.

~Andrew

P.S. The end goal is to have DOMCTL_createdomain return the domid via
return value not in the struct, at which point the entire struct becomes
input-only, and substantially easier in the new API/ABI design.  Also
createdomain really should be a SYSCTL not a domctl, and that will help
to simplify do_domctl() a little.

Le 09/07/2026 à 15:22, Julian Vetter a écrit :
> When creating a domain on ARM, and passing XEN_DOMCTL_CONFIG_GIC_NATIVE
> for the gic_version field in the struct xen_arch_domainconfig,
> arch_sanitise_domain_config() resolves this to the approrpiate GIC_V2 or
> GIC_V3 version the domain actually has, based on the host's
> gic_hw_version(). That value is stored in the domain as
> d->arch.vgic.version, but can't be queried through any other domctl
> later. Toolstacks that create and build a domain in the same call
> already have this info from the createdomain reply and never need to ask
> again.
> 
> Toolstacks that create a domain and build it later from a separate
> process do need to ask again. But, the ARM implementation only fills in
> info->flags and info->gpaddr_bits. info->arch_config is left zeroed, so
> XEN_DOMCTL_getdomaininfo always reports gic_version as
> XEN_DOMCTL_CONFIG_GIC_NATIVE (0) regardless of what was actually
> configured earlier.
> 
> Signed-off-by: Julian Vetter <julian.vetter@vates.tech>
> ---
>   xen/arch/arm/domctl.c | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
> index 6c9a3f9920..b76af56fad 100644
> --- a/xen/arch/arm/domctl.c
> +++ b/xen/arch/arm/domctl.c
> @@ -24,6 +24,8 @@ void arch_get_domain_info(const struct domain *d,
>       info->flags |= XEN_DOMINF_hap;
>   
>       info->gpaddr_bits = p2m_ipa_bits;
> +
> +    info->arch_config.gic_version = d->arch.vgic.version;
>   }
>   
>   static int handle_vuart_init(struct domain *d,

That probably wants a Fixes: note given that the current behavior is 
incomplete.

Although, there are a few issues, the hypercall part 
(arch_config.gic_version) uses

#define XEN_DOMCTL_CONFIG_GIC_NATIVE    0
#define XEN_DOMCTL_CONFIG_GIC_V2        1
#define XEN_DOMCTL_CONFIG_GIC_V3        2

while internal ARM code (arch.vgic.version) uses

enum gic_version {
     GIC_INVALID = 0,    /* the default until explicitly set up */
     GIC_V2,
     GIC_V3,
};

That happens to match, but that may want to be adjusted to not break in 
case these 2 representations diverges.

Teddy