Re: [PATCH v2] xen/arm, xen/common: Add Kconfig option to control Dom0 boot

["Orzel, Michal" <michal.orzel@xxxxxxx>]

On 28/07/2025 19:07, Oleksii Moisieiev wrote:
> This commit introduces a new Kconfig option, `CONFIG_DOM0_BOOT`, to
> allow for building Xen without support for booting a regular domain (Dom0).
> This functionality is primarily intended for the ARM architecture.
> 
> A new Kconfig symbol, `HAS_DOM0`, has been added and is selected by
> default for ARM and X86 architecture. This symbol signifies that an
> architecture has the capability to support a Dom0.
> 
> The `DOM0_BOOT` option depends on `HAS_DOM0` and defaults to 'y'. For
> expert users, this option can be disabled (`CONFIG_EXPERT=y` and no
> `CONFIG_DOM0_BOOT` in the config), which will compile out the Dom0
> creation code on ARM. This is useful for embedded or dom0less-only
> scenarios to reduce binary size and complexity.
> 
> The ARM boot path has been updated to panic if it detects a non-dom0less
> configuration while `CONFIG_DOM0_BOOT` is disabled, preventing an invalid
> boot.
> 
> Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@xxxxxxxx>
> 
> ---
> 
> Changes in v2:
> - decided not to rename HAS_DOM0 (HAS_OPTIONAL_DOM0 was another option
> suggested in ML) because in this case HAS_DOM0LESS should be renamed
> either.
> - fix order of HAS_DOM0 config parameter
> - add HAS_DOM0 option to x86 architecture.
> 
> CONFIG_DOM0_BOOT Kconfig option was introduced to make the Dom0
> regular (legacy) domain an optional feature that can be compiled out
> from the Xen hypervisor build.
> 
> The primary motivation for this change is to enhance modularity and
> produce a cleaner, more specialized hypervisor binary when a control
> domain is not needed. In many embedded or dedicated systems, Xen is
> used in a "dom0less" configuration where guests are pre-configured and
> launched directly by the hypervisor. In these scenarios, the entire
> subsystem for booting and managing Dom0 is unnecessary.
> 
> This approach aligns with software quality standards like MISRA C,
> which advocate for the removal of unreachable or unnecessary code to
> improve safety and maintainability. Specifically, this change helps adhere to:
> 
> MISRA C:2012, Rule 2.2: "There shall be no dead code"
> 
> In a build configured for a dom0less environment, the code responsible
> for creating Dom0 would be considered "dead code" as it would never be
> executed. By using the preprocessor to remove it before compilation,
> we ensure that the final executable is free from this unreachable
> code. This simplifies static analysis, reduces the attack surface,
> and makes the codebase easier to verify, which is critical for
> systems requiring high levels of safety and security.
> 
> ---
>  xen/arch/arm/Kconfig        |  1 +
>  xen/arch/arm/domain_build.c |  8 ++++++++
>  xen/arch/arm/setup.c        | 14 ++++++++++----
>  xen/arch/x86/Kconfig        |  1 +
>  xen/common/Kconfig          | 11 +++++++++++
>  5 files changed, 31 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index bf6d1cf88e..74da544925 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -18,6 +18,7 @@ config ARM
>       select GENERIC_UART_INIT
>       select HAS_ALTERNATIVE if HAS_VMAP
>       select HAS_DEVICE_TREE
> +     select HAS_DOM0
>       select HAS_DOM0LESS
>       select HAS_GRANT_CACHE_FLUSH if GRANT_TABLE
>       select HAS_STACK_PROTECTOR
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index ed668bd61c..9b8993df80 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -40,8 +40,10 @@
>  #include <asm/grant_table.h>
>  #include <xen/serial.h>
>  
> +#ifdef CONFIG_DOM0_BOOT
>  static unsigned int __initdata opt_dom0_max_vcpus;
>  integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
> +#endif
>  
>  /*
>   * If true, the extended regions support is enabled for dom0 and
> @@ -102,6 +104,7 @@ int __init parse_arch_dom0_param(const char *s, const 
> char *e)
Why is this and other dom0 cmdline parsing functions not disabled?
What is your method of deciding what to compile out or not?

>   */
>  #define DOM0_FDT_EXTRA_SIZE (128 + sizeof(struct fdt_reserve_entry))
>  
> +#ifdef CONFIG_DOM0_BOOT
>  unsigned int __init dom0_max_vcpus(void)
>  {
>      if ( opt_dom0_max_vcpus == 0 )
> @@ -114,6 +117,7 @@ unsigned int __init dom0_max_vcpus(void)
>  
>      return opt_dom0_max_vcpus;
>  }
> +#endif
>  
>  /*
>   * Insert the given pages into a memory bank, banks are ordered by address.
> @@ -1953,6 +1957,7 @@ int __init construct_domain(struct domain *d, struct 
> kernel_info *kinfo)
>      return 0;
>  }
>  
> +#ifdef CONFIG_DOM0_BOOT
>  static int __init construct_dom0(struct domain *d)
>  {
>      struct kernel_info kinfo = KERNEL_INFO_INIT;
> @@ -1984,6 +1989,7 @@ static int __init construct_dom0(struct domain *d)
>  
>      return construct_hwdom(&kinfo, NULL);
>  }
> +#endif
>  
>  int __init construct_hwdom(struct kernel_info *kinfo,
>                             const struct dt_device_node *node)
> @@ -2037,6 +2043,7 @@ int __init construct_hwdom(struct kernel_info *kinfo,
>      return construct_domain(d, kinfo);
>  }
>  
> +#ifdef CONFIG_DOM0_BOOT
>  void __init create_dom0(void)
>  {
>      struct domain *dom0;
> @@ -2089,6 +2096,7 @@ void __init create_dom0(void)
>  
>      set_xs_domain(dom0);
>  }
> +#endif /* CONFIG_DOM0_BOOT */
>  
>  /*
>   * Local variables:
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 12b76a0a98..c1463d647a 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -480,12 +480,18 @@ void asmlinkage __init start_xen(unsigned long 
> fdt_paddr)
>      enable_errata_workarounds();
>      enable_cpu_features();
>  
> -    /* Create initial domain 0. */
> -    if ( !is_dom0less_mode() )
> +    if ( IS_ENABLED(CONFIG_DOM0_BOOT) && !is_dom0less_mode() )
> +    {
> +        /* Create initial domain 0. */
>          create_dom0();
> +    }
>      else
> -        printk(XENLOG_INFO "Xen dom0less mode detected\n");
> -
> +    {
> +        if ( is_dom0less_mode())
> +            printk(XENLOG_INFO "Xen dom0less mode detected\n");
> +        else
> +            panic("Xen dom0less mode not detected, aborting boot\n");
I think it should mention that neither dom0 nor dom0less mode not detected

> +    }
>      if ( acpi_disabled )
>      {
>          create_domUs();
> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> index a45ce106e2..06e2888707 100644
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -18,6 +18,7 @@ config X86
>       select HAS_COMPAT
>       select HAS_CPUFREQ
>       select HAS_DIT
> +     select HAS_DOM0
>       select HAS_EHCI
>       select HAS_EX_TABLE
>       select HAS_FAST_MULTIPLY
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index 64865112a1..22e8192a7d 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -21,6 +21,14 @@ config DOM0LESS_BOOT
>         Xen boot without the need of a control domain (Dom0), which could be
>         present anyway.
>  
> +config DOM0_BOOT
> +     bool "Dom0 boot support" if EXPERT
> +     depends on HAS_DOM0 && HAS_DEVICE_TREE && DOMAIN_BUILD_HELPERS
> +     default y
> +     help
> +       Dom0 boot support enables Xen to boot to the control domain (Dom0) and
dom0 is also a hardware and xenstore domain if you want to list all
capabilities. That said, dom0 is a very known concept, so you could just write
all-powerful domain.

> +       manage domU guests using the Xen toolstack with provided 
> configurations.
I'm not sure we need this line. Why would we make assumption what user wants to
use dom0 for?

~Michal