Re: [PATCH v2 3/4] xen/arm64: allow to make aarch32 support optional

[Grygorii Strashko <grygorii_strashko@xxxxxxxx>]

Hi

On 05.09.25 16:07, Julien Grall wrote:
> On 05/09/2025 13:15, Volodymyr Babchuk wrote:
> > Hi,
> >
> > Grygorii Strashko <grygorii_strashko@xxxxxxxx> writes:
> >
> > > On 27.08.25 03:16, Volodymyr Babchuk wrote:
> > > > Hi Grygorii,
> > > > Grygorii Strashko <grygorii_strashko@xxxxxxxx> writes:
> > > >
> > > > > From: Grygorii Strashko <grygorii_strashko@xxxxxxxx>
> > > > >
> > > > > 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_strashko@xxxxxxxx>
> > > > > ---
> > > > > 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).
If I understood comments about Kconfig option correctly (which I might not be):
- Not sure if it can be called a "feature" it rather optimization (enabled 
optionally)
- From my point of view it's basically completed
- The "Arm64 AArch32 guest support" is not mentioned SUPPORT.MD

I'm not sure what support level can be considered for "Arm64 AArch32 guest 
support"
hence there was no related Kconfig option before.

if treat "Arm64 AArch32 guest support" as : "Supported"
(a) by default ARM64_AARCH32=y, so no changes in Xen default behavior or 
interfaces
(b) switching to ARM64_AARCH32=n might change status and seems fall under
   "EXPERT and DEBUG Kconfig options are not security supported."

if treat status other than "Supported" - probably no need to depend from EXPERT.

I'm going to change dependency to EXPERT in the next version.

> 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.
Thanks a lot for your comments.

--
Best regards,
-grygorii