Hi Demi,

On 05.09.25 06:43, Demi Marie Obenour wrote:
On 8/6/25 05:49, Grygorii Strashko wrote:
From: Grygorii Strashko <grygorii_stras...@epam.com>

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.

Hence, this patch introduces basic support to allow make Arm64
AArch32 guest support optional. The following changes are introduced:

- Introduce Kconfig option CONFIG_ARM64_AARCH32 to allow enable/disable
   Arm64 AArch32 guest support (default y)

- Introduce is_aarch32_enabled() helper which accounts Arm64 HW capability
   and CONFIG_ARM64_AARCH32 setting

- Introduce arm64_set_domain_type() to configure Arm64 domain type in
   unified way instead of open coding (d)->arch.type, and account
   CONFIG_ARM64_AARCH32 configuration.

- toolstack: do not advertise "xen-3.0-armv7l " capability if AArch32 is
   disabled.

- do not expose EL1 AArch32 support to guest in ID_AA64PFR0_EL1 reg if
   AArch32 is disabled.

- Set Arm64 domain type to DOMAIN_64BIT by default.
   - the Arm Xen boot code is handling this case properly already;
   - for toolstack case the XEN_DOMCTL_set_address_size hypercall handling
     updated to forcibly configure domain type regardless of current domain
     type configuration, so toolstack behavior is unchanged.

With CONFIG_ARM64_AARCH32=n the Xen will reject AArch32 guests (kernels) if
configured by user in the following way:
- Xen boot will fail with panic during dom0 or dom0less domains creation
- toolstack domain creation will be rejected due to xc_dom_compat_check()
   failure.

Making Arm64 AArch32 guest support open further possibilities for build
optimizations of Arm64 AArch32 guest support code.

Signed-off-by: Grygorii Strashko <grygorii_stras...@epam.com>
---
changes in v2:
- 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

  xen/arch/arm/Kconfig                    |  7 ++++
  xen/arch/arm/arm64/domain-build.c       | 46 +++++++++++++++++++++++--
  xen/arch/arm/arm64/domctl.c             | 16 +++++----
  xen/arch/arm/arm64/vsysreg.c            |  9 +++++
  xen/arch/arm/domain.c                   |  9 +++++
  xen/arch/arm/domain_build.c             | 21 +++--------
  xen/arch/arm/include/asm/arm32/domain.h | 12 +++++++
  xen/arch/arm/include/asm/arm64/domain.h | 23 +++++++++++++
  xen/arch/arm/setup.c                    |  2 +-
  9 files changed, 119 insertions(+), 26 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index a0c816047427..bf6dd73caf73 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -266,6 +266,13 @@ config PCI_PASSTHROUGH
        help
          This option enables PCI device passthrough
+config ARM64_AARCH32
+       bool "AArch32 Guests support on on ARM64 (UNSUPPORTED)" if UNSUPPORTED
+       depends on ARM_64
+       default y
+       help
+         This option enables AArch32 Guests on ARM64.
+
  endmenu
Why UNSUPPORTED?  A safety-certified build of Xen should only be using
security-supported features.

I'd probably introduced a confusion here due to my limited experience with
Xen upstream, sorry for that.

What I've tried to note with "UNSUPPORTED" is that it's new option, which 
allows to
change default Xen cfg.

After re-checking existing Kconfig files - I think correct way will be:
- change dependency to EXPERT
- remove "UNSUPPORTED"

Will it be ok?


Thank you for you comments.

--
Best regards,
-grygorii


Reply via email to