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 | 65 ++++++++++++++++++++ xen/arch/arm/arm64/domain.c | 5 ++ xen/arch/arm/arm64/domctl.c | 6 ++ xen/arch/arm/dom0less-build.c | 14 ----- xen/arch/arm/domain.c | 9 ++- xen/arch/arm/domain_build.c | 33 +++------- xen/arch/arm/include/asm/arm32/domain.h | 28 +++++++++ xen/arch/arm/include/asm/arm32/processor.h | 5 ++ xen/arch/arm/include/asm/arm64/domain.h | 71 ++++++++++++++++++++++ xen/arch/arm/include/asm/arm64/processor.h | 19 ++++++ xen/arch/arm/include/asm/domain.h | 9 ++- xen/arch/arm/include/asm/regs.h | 24 -------- xen/arch/arm/setup.c | 2 +- xen/common/device-tree/dom0less-build.c | 6 +- xen/include/asm-generic/dom0less-build.h | 9 +++ 19 files changed, 258 insertions(+), 78 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
From: Grygorii Strashko <grygorii_strashko@epam.com>
Hi,
Now Arm64 AArch32 guest support is always enabled and built-in while not
all Arm64 platforms supports AArch32 or this support might not be needed.
Hence, this series introduces basic support for disabling Arm64 AArch32
guest support by introducing Kconfig option CONFIG_ARM64_AARCH32 to allow enable/disable
Arm64 AArch32 guest support (default y).
Patches 1-4 Prerequisite patches
Patch 5 - Introduces Kconfig option CONFIG_ARM64_AARCH32 and prevents creating domains
running Arm64 AArch32 guests if CONFIG_ARM64_AARCH32=n
Patches 6-8 - enables build-time optimization of AArch32 specific code by redefining some
macro (like is_32/64bit_domain()) as constants
Grygorii Strashko (8):
xen/arm: split set_domain_type() between arm64/arm32
xen/arm: move vcpu_switch_to_aarch64_mode() in arch_vcpu_create()
xen/arm: move vcpu_switch_to_aarch64_mode() in arm64
xen/arm: split is_32bit/64bit_domain() between arm64/arm32
xen/arm64: make aarch32 support optional
xen/arm64: constify is_32/64bit_domain() macro for CONFIG_ARM64_AARCH32=n
xen/arm: regs.h split subarch definitions between arm64/arm32
xen/arm64: constify regs_mode_is_32bit 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 | 65 ++++++++++++++++++++
xen/arch/arm/arm64/domain.c | 5 ++
xen/arch/arm/arm64/domctl.c | 6 ++
xen/arch/arm/dom0less-build.c | 14 -----
xen/arch/arm/domain.c | 9 ++-
xen/arch/arm/domain_build.c | 33 +++-------
xen/arch/arm/include/asm/arm32/domain.h | 28 +++++++++
xen/arch/arm/include/asm/arm32/processor.h | 5 ++
xen/arch/arm/include/asm/arm64/domain.h | 71 ++++++++++++++++++++++
xen/arch/arm/include/asm/arm64/processor.h | 19 ++++++
xen/arch/arm/include/asm/domain.h | 9 ++-
xen/arch/arm/include/asm/regs.h | 24 --------
xen/arch/arm/setup.c | 2 +-
xen/common/device-tree/dom0less-build.c | 6 +-
xen/include/asm-generic/dom0less-build.h | 9 +++
19 files changed, 258 insertions(+), 78 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
On 23/07/2025 08:58, Grygorii Strashko wrote: > From: Grygorii Strashko <grygorii_strashko@epam.com> > > Hi, Hi Grygorii, > Now Arm64 AArch32 guest support is always enabled and built-in while not > all Arm64 platforms supports AArch32 or this support might not be needed. I am not entirely sure I like the proliferation of using CONFIG_* for every single feature. This makes the testing a bit more complicated. Can you clarify what the goal with this patch? Cheers, -- Julien Grall
On 23/07/2025 10:06, Julien Grall wrote: > > > On 23/07/2025 08:58, Grygorii Strashko wrote: >> From: Grygorii Strashko <grygorii_strashko@epam.com> >> >> Hi, > > Hi Grygorii, > >> Now Arm64 AArch32 guest support is always enabled and built-in while not >> all Arm64 platforms supports AArch32 or this support might not be needed. > > I am not entirely sure I like the proliferation of using CONFIG_* for > every single feature. This makes the testing a bit more complicated. > > Can you clarify what the goal with this patch? AArch32 is used quite rarely in embedded systems. Also, in Armv9A it might only be implemented at EL0 if at all. 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 us with two options: either support it (lots of additional testing, requirements and documents would be needed) or compile it out. ~Michal
On 23.07.25 13:54, Orzel, Michal wrote: > > > On 23/07/2025 10:06, Julien Grall wrote: >> >> >> On 23/07/2025 08:58, Grygorii Strashko wrote: >>> From: Grygorii Strashko <grygorii_strashko@epam.com> >>> >>> Hi, >> >> Hi Grygorii, >> >>> Now Arm64 AArch32 guest support is always enabled and built-in while not >>> all Arm64 platforms supports AArch32 or this support might not be needed. >> >> I am not entirely sure I like the proliferation of using CONFIG_* for >> every single feature. This makes the testing a bit more complicated. >> >> Can you clarify what the goal with this patch? > AArch32 is used quite rarely in embedded systems. Also, in Armv9A it might only > be implemented at EL0 if at all. 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 us with two options: either support it (lots of > additional testing, requirements and documents would be needed) or compile it out. FYI. bloat-o-meter report for this series with CONFIG_ARM64_AARCH32=n, CONFIG_EXPERT=y add/remove: 0/6 grow/shrink: 2/32 up/down: 276/-5672 (-5396) Function old new delta do_trap_guest_sync 1588 1856 +268 start_xen 2456 2464 +8 make_cpus_node 832 820 -12 arch_vcpu_create 328 312 -16 vfp_save_state 132 112 -20 vfp_restore_state 132 112 -20 is_guest_pv32_psr 20 - -20 construct_hwdom 1208 1188 -20 construct_domU 2544 2524 -20 make_hypervisor_node 2048 2016 -32 inject_undef64_exception 112 80 -32 inject_abt64_exception 164 132 -32 show_registers 260 224 -36 arm64_set_domain_type 128 88 -40 do_deprecated_hypercall 124 80 -44 construct_domain 316 272 -44 init_xen_cap_info 96 44 -52 continue_new_vcpu 188 136 -52 check_conditional_instr 192 140 -52 vsmccc_handle_call 1328 1272 -56 make_timer_node 492 436 -56 vcpu_regs_user_to_hyp 512 448 -64 vcpu_regs_hyp_to_user 512 448 -64 do_common_cpu_on 440 372 -68 cpsr_switch_mode 80 - -80 advance_pc 140 32 -108 do_trap_stage2_abort_guest 836 724 -112 arch_set_info_guest 336 184 -152 inject_undef_exception 180 20 -160 arch_do_multicall_call 632 468 -164 schedule_tail 752 576 -176 decode_thumb2 200 - -200 subarch_do_domctl 276 40 -236 inject_abt32_exception 236 - -236 do_debug_trap 256 - -256 hypercall_create_continuation 1228 848 -380 _show_registers 832 380 -452 decode_instruction 1032 476 -556 do_trap_hypercall 640 - -640 guest_walk_tables 1896 984 -912 Total: Before=670920, After=665524, chg -0.80% add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) Data old new delta Total: Before=448625, After=448625, chg +0.00% add/remove: 0/0 grow/shrink: 1/0 up/down: 191/0 (191) RO Data old new delta xen_config_data 1345 1536 +191 Total: Before=18498, After=18689, chg +1.03% -- Best regards, -grygorii
Hi, On 23/07/2025 12:48, Grygorii Strashko wrote: > > > On 23.07.25 13:54, Orzel, Michal wrote: >> >> >> On 23/07/2025 10:06, Julien Grall wrote: >>> >>> >>> On 23/07/2025 08:58, Grygorii Strashko wrote: >>>> From: Grygorii Strashko <grygorii_strashko@epam.com> >>>> >>>> Hi, >>> >>> Hi Grygorii, >>> >>>> Now Arm64 AArch32 guest support is always enabled and built-in while >>>> not >>>> all Arm64 platforms supports AArch32 or this support might not be >>>> needed. >>> >>> I am not entirely sure I like the proliferation of using CONFIG_* for >>> every single feature. This makes the testing a bit more complicated. >>> >>> Can you clarify what the goal with this patch? >> AArch32 is used quite rarely in embedded systems. Also, in Armv9A it >> might only >> be implemented at EL0 if at all. 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 us with two options: either support it >> (lots of >> additional testing, requirements and documents would be needed) or >> compile it out. > > FYI. bloat-o-meter report for this series with CONFIG_ARM64_AARCH32=n, > CONFIG_EXPERT=y Thanks for sharing the bloat-o-meter. But I don't think the result below warrant a new config. The reason provided by Michal is a better reason as the impact on safety certification is more significant. Cheers, -- Julien Grall
On 23.07.25 15:02, Julien Grall wrote: > Hi, > > On 23/07/2025 12:48, Grygorii Strashko wrote: >> >> >> On 23.07.25 13:54, Orzel, Michal wrote: >>> >>> >>> On 23/07/2025 10:06, Julien Grall wrote: >>>> >>>> >>>> On 23/07/2025 08:58, Grygorii Strashko wrote: >>>>> From: Grygorii Strashko <grygorii_strashko@epam.com> >>>>> >>>>> Hi, >>>> >>>> Hi Grygorii, >>>> >>>>> Now Arm64 AArch32 guest support is always enabled and built-in while not >>>>> all Arm64 platforms supports AArch32 or this support might not be needed. >>>> >>>> I am not entirely sure I like the proliferation of using CONFIG_* for >>>> every single feature. This makes the testing a bit more complicated. >>>> >>>> Can you clarify what the goal with this patch? >>> AArch32 is used quite rarely in embedded systems. Also, in Armv9A it might only >>> be implemented at EL0 if at all. 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 us with two options: either support it (lots of >>> additional testing, requirements and documents would be needed) or compile it out. >> >> FYI. bloat-o-meter report for this series with CONFIG_ARM64_AARCH32=n, CONFIG_EXPERT=y > > Thanks for sharing the bloat-o-meter. But I don't think the result below warrant a new config. The reason provided by Michal is a better reason as the impact on safety certification is more significant. It just an additional info to illustrate achieved build-time optimization results which reduces coverage gaps. -- Best regards, -grygorii
Hi All, On 23.07.25 15:12, Grygorii Strashko wrote: > > > On 23.07.25 15:02, Julien Grall wrote: >> Hi, >> >> On 23/07/2025 12:48, Grygorii Strashko wrote: >>> >>> >>> On 23.07.25 13:54, Orzel, Michal wrote: >>>> >>>> >>>> On 23/07/2025 10:06, Julien Grall wrote: >>>>> >>>>> >>>>> On 23/07/2025 08:58, Grygorii Strashko wrote: >>>>>> From: Grygorii Strashko <grygorii_strashko@epam.com> >>>>>> >>>>>> Hi, >>>>> >>>>> Hi Grygorii, >>>>> >>>>>> Now Arm64 AArch32 guest support is always enabled and built-in while not >>>>>> all Arm64 platforms supports AArch32 or this support might not be needed. >>>>> >>>>> I am not entirely sure I like the proliferation of using CONFIG_* for >>>>> every single feature. This makes the testing a bit more complicated. >>>>> >>>>> Can you clarify what the goal with this patch? >>>> AArch32 is used quite rarely in embedded systems. Also, in Armv9A it might only >>>> be implemented at EL0 if at all. 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 us with two options: either support it (lots of >>>> additional testing, requirements and documents would be needed) or compile it out. >>> >>> FYI. bloat-o-meter report for this series with CONFIG_ARM64_AARCH32=n, CONFIG_EXPERT=y >> >> Thanks for sharing the bloat-o-meter. But I don't think the result below warrant a new config. > The reason provided by Michal is a better reason as the impact on safety certification is more significant. > > It just an additional info to illustrate achieved build-time optimization results > which reduces coverage gaps. > Would it be reasonable to send patches which split arm64/arm32 code separately (Patches 1,3,4,7)? (with comments applied). -- Best regards, -grygorii
© 2016 - 2025 Red Hat, Inc.