[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [PATCH v2 0/4] xen/arm64: allow to make aarch32 support optional
From: Grygorii Strashko <grygorii_strashko@xxxxxxxx> Hi, During review of v1 [1] of this series Julien Grall raised concern that "If the desire is to make 32-bit domain optional on Arm64. Then I think it would be better to pass the domain type when the domain is created (IOW add an extra flags to XEN_DOMCTL_createdomain)." for which I've sent patches attempting to start solving the problem [2] and try to probe guest kernels before creating domains. While proposed changes [2] is under review and hence there are definitely more work is required I'd appreciated if current series can be considered as it's Arm specific only and working (and tested) with current Xen in its current state. Now Arm64 AArch32 guest support is always enabled and built-in while not all Arm64 platforms supports AArch32 (for exmaple on Armv9A) or this support might not be needed (Arm64 AArch32 is used quite rarely in embedded systems). More over, when focusing on safety certification, AArch32 related code in Xen leaves a gap in terms of coverage that cannot really be justified in words. This leaves two options: either support it (lots of additional testing, requirements and documents would be needed) or compile it out. Patches 1-2 Prerequisite patches Patch 3 - allows to make aarch32 support optional by introducing Kconfig option CONFIG_ARM64_AARCH32 Patch 4 - enables build-time optimization of AArch32 specific code by redefining some is_32/64bit_domain() macro as constants Tested (CONFIG_ARM64_AARCH32=y/n): - dom0 with AArch32/64 kernel - toolstack create domain with AArch32/64 kernel - dom0less domains with AArch32/64 kernel - creating domain with AArch64 kernel and AArch32 EL0 rootfs Changes in v2: - dropped patches - (licensing issue) "xen/arm: move vcpu_switch_to_aarch64_mode() in arch_vcpu_create()" - (problematic change) "xen/arm: move vcpu_switch_to_aarch64_mode() in arm64" - constifying is_32/64bit_domain() macro gives most of results in terms of coverage, drop regs changes for now (can be added latter): "xen/arm: regs.h split subarch definitions between arm64/arm32" "xen/arm64: constify regs_mode_is_32bit macro for CONFIG_ARM64_AARCH32=n" - use Arm64 "cpu_has_el1_32" in all places to check if HW has AArch32 support - rework Arm64 XEN_DOMCTL_set_address_size hypercall handling to work with any initial domain type set (32bit or 64 bit) - fix comments related to macro parameters evaluation issues - do not expose EL1 AArch32 support to guest in ID_AA64PFR0_EL1 reg if AArch32 is disabled Link on v1: [1] https://lore.kernel.org/xen-devel/20250723075835.3993182-1-grygorii_strashko@xxxxxxxx/ [2] https://patchwork.kernel.org/project/xen-devel/cover/20250731094234.996684-1-grygorii_strashko@xxxxxxxx/ Grygorii Strashko (4): xen/arm: split set_domain_type() between arm64/arm32 xen/arm: split is_32bit/64bit_domain() between arm64/arm32 xen/arm64: allow to make aarch32 support optional xen/arm64: constify is_32/64bit_domain() macro for CONFIG_ARM64_AARCH32=n xen/arch/arm/Kconfig | 7 +++ xen/arch/arm/arm32/Makefile | 1 + xen/arch/arm/arm32/domain-build.c | 22 +++++++++ xen/arch/arm/arm64/Makefile | 1 + xen/arch/arm/arm64/domain-build.c | 66 +++++++++++++++++++++++++ xen/arch/arm/arm64/domctl.c | 16 +++--- xen/arch/arm/arm64/vsysreg.c | 9 ++++ xen/arch/arm/dom0less-build.c | 14 ------ xen/arch/arm/domain.c | 9 ++++ xen/arch/arm/domain_build.c | 21 ++------ xen/arch/arm/include/asm/arm32/domain.h | 32 ++++++++++++ xen/arch/arm/include/asm/arm64/domain.h | 54 ++++++++++++++++++++ xen/arch/arm/include/asm/domain.h | 7 ++- xen/arch/arm/setup.c | 2 +- xen/include/xen/dom0less-build.h | 8 +++ 15 files changed, 227 insertions(+), 42 deletions(-) create mode 100644 xen/arch/arm/arm32/domain-build.c create mode 100644 xen/arch/arm/arm64/domain-build.c create mode 100644 xen/arch/arm/include/asm/arm32/domain.h create mode 100644 xen/arch/arm/include/asm/arm64/domain.h -- 2.34.1
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |