mirror of
https://github.com/xen-project/xen.git
synced 2026-10-28 02:01:24 +01:00
Julian Vetter
93e976a1d1
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 the GIC version against those bits before the config is built. An unspecified version becomes v3 if available, else v2, else fails. An explicitly requested v2/v3 is validated against the same bits, so a version the host cannot provide is directly rejected in the toolstack. * 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. LIBXL_GIC_VERSION_DEFAULT keeps its name and value: xl.cfg still accepts "default" as the C<gic_version> keyword, and setdefault() resolves it to a concrete v2/v3 before anything else can observe it. 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 <julian.vetter@vates.tech> Acked-by: Michal Orzel <michal.orzel@amd.com> Acked-by: Anthony PERARD <anthony.perard@vates.tech>