On 05/09/2025 13:15, Volodymyr Babchuk wrote:
Hi,
Grygorii Strashko <grygorii_stras...@epam.com> writes:
On 27.08.25 03:16, Volodymyr Babchuk wrote:
Hi Grygorii,
Grygorii Strashko <grygorii_stras...@epam.com> writes:
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
But aarch32 guests are supported... I understand that you wanted to
say
"Disabling aarch32 support is unsupported". But currently this entry
reads backwards. I think it should be reworded better. But I have no
idea - how to do this.
I think "(UNSUPPORTED)" can be just dropped. Is it ok?
As I understand, If you want this feature to be eventually certified, it
should not be UNSUPPORTED nor EXPERIMENTAL.
The certification is somewhat irrelevant to the decision of the state of
the feature. Instead, the decision should be based on the criteria based
in SUPPORT.MD (see "Status"). If it is experimental/unsupported, then
what's missing to make it supported?
In addition to that, there is the "EXPERT" mode. This was introduced
mainly to allow the user to tailor the Kconfig but also limit to what we
security support. This is to reduce the amount of workload on the
security team when it comes to decide on whether we need to issue an XSA
(the more possibility, the more difficult it becomes).
There has been discussion on providing a small set of config (one could
be for certification purpose) that would be security supported. But I
don't think we come to a conclusion yet.
Cheers,
--
Julien Grall
