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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 02.10.2026 15:26, 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.

I (still) wonder why this would be, but well ...

> 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.

Oleksii - what's your take towards RISC-V here? Should it select the new
symbol right away as well?

> 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>
> Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

Notwithstanding the ack, a few further comments.

> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -43,8 +43,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
> @@ -123,6 +125,7 @@ paddr_t __init hwdom_get_fdt_alloc_size(void)
>      return ACPI_DOM0_FDT_MIN_SIZE;
>  }
>  
> +#ifdef CONFIG_DOM0_BOOT
>  unsigned int __init dom0_max_vcpus(void)
>  {
>      if ( opt_dom0_max_vcpus == 0 )
> @@ -135,6 +138,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.
> @@ -1862,6 +1866,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;
> @@ -1893,6 +1898,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)
> @@ -1944,6 +1950,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;
> @@ -2001,6 +2008,7 @@ void __init create_dom0(void)
>  
>      set_xs_domain(dom0);
>  }
> +#endif /* CONFIG_DOM0_BOOT */

It's not really a lot of code which is being removed, which may suggest this
is getting too fine-grained. (Primarily, for now) Arm maintainers will need
to judge.

I further wonder how much unreachable code is newly introduced by this, when
the new option is enabled. set_xs_domain() (visible in patch context above)
is possibly only the first example.

> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -491,11 +491,18 @@ void asmlinkage __init noreturn start_xen(unsigned long 
> fdt_paddr)
>  
>      do_init_boottests();
>  
> -    /* 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("Neither dom0 nor dom0less mode was detected, aborting\n");
> +    }

If I was maintainer of this code, I would ask for the figure braces to be
omitted - the inner if() can easily be "else if".

> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -26,6 +26,15 @@ 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 && !X86

Like already indicated in reply to v3 I'm irritated by this: What use is
the select of HAS_DOM0 on x86 when then you exclude x86 here? I think it
needs to be clarified whether, as the commit message says, this is going
to be Arm-only or of broader use. In the latter case the !X86 here would
want leaving out; the description then would want to clarify that making
x86 respect the option is a TODO item (possibly part of the hyperlaunch
effort).

In the former case more questions arise, like why this wants to be a
common option in the first place. (But since from an abstract pov this is
a common choice, this case likely doesn't want pursuing anyway.)

Jan