Re: [PATCH v4 3/6] tools/arm: choose GIC version explicitly instead of relying on GIC_NATIVE

"Orzel, Michal" <[email protected]>
Newsgroups gmane.comp.emulators.xen.devel
Message-ID <[email protected]>

On 20-Aug-26 14:40, Julian Vetter wrote:
> XEN_DOMCTL_CONFIG_GIC_NATIVE lets the toolstack ask Xen to silently
> resolve the domain's GIC version to whatever the host hardware has. Xen
> then writes the resolved value back into the same in/out
> xen_arch_domainconfig the toolstack used as input, which is the kind of
> API abuse we're trying to get rid of. The struct passed to createdomain
> should only be an input parameter.
> 
> Move the "pick the best available GIC version" decision to the
> toolstack, using the XEN_SYSCTL_PHYSCAP_ARM_GIC_V2/V3 capability bits
> already exposed via XEN_SYSCTL_physinfo:
> 
>  * libxl__arch_domain_build_info_setdefault() resolves
>    LIBXL_GIC_VERSION_DEFAULT to v3 if available, else v2, else fails,
`LIBXL_GIC_VERSION_DEFAULT` should be renamed to `LIBXL_GIC_VERSION_NONE` to
denote that the user did not set any particular version. With your change there
is no default and `libxl__arch_domain_build_info_setdefault()` resolves it
before anything else can see it.

>    before the config is built.
>  * The Python xc.domain_create() binding does the same via a call to
>    xc_physinfo().
>  * libxl__arch_domain_prepare_config() therefore only ever sees a
>    concrete v2/v3 request and just validates it. The GIC_NATIVE case is
>    dropped since setdefault() always resolves it first.
> 
> This guarantees no toolstack path can still produce
> XEN_DOMCTL_CONFIG_GIC_NATIVE, in preparation for removing it from the
> Xen side and from the ABI entirely.
> 
> Signed-off-by: Julian Vetter <[email protected]>
> ---
> Changes in v4:
> - Fix a missing closing bracket in arch_capabilities_arm_has()
> ---
>  .../include/xen-tools/arm-arch-capabilities.h | 17 ++++++++++++++++
>  tools/libs/light/libxl_arm.c                  | 17 +++++++++++++---
>  tools/python/xen/lowlevel/xc/xc.c             | 20 ++++++++++++++++++-
You need to update the documentation (i.e. xl.cfg) too.

>  3 files changed, 50 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/include/xen-tools/arm-arch-capabilities.h b/tools/include/xen-tools/arm-arch-capabilities.h
> index 4aa4c6c34a..ce1b3bdd71 100644
> --- a/tools/include/xen-tools/arm-arch-capabilities.h
> +++ b/tools/include/xen-tools/arm-arch-capabilities.h
> @@ -6,6 +6,7 @@
>  #ifndef ARM_ARCH_CAPABILITIES_H
>  #define ARM_ARCH_CAPABILITIES_H
>  
> +#include <stdbool.h>
>  #include <stdint.h>
>  #include <xen/sysctl.h>
>  
> @@ -25,4 +26,20 @@ unsigned int arch_capabilities_arm_sve(unsigned int arch_capabilities)
>  #endif
>  }
>  
> +/*
> + * Generic test for any single-bit XEN_SYSCTL_PHYSCAP_ARM_* capability, e.g.
What makes the implementation single-bit?

Otherwise, LGTM.

~Michal
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.