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_moisie...@epam.com>
>
> ---
>
> 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
