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