[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v2] xen/arm, xen/common: Add Kconfig option to control Dom0 boot
Hi Michal, On 29/07/2025 10:22, Orzel, Michal wrote: > 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? I've compiled with the following flags: "-ffunction-sections -Wl,--gc-sections -Wunused-functio" Also I was analyzing coverage reports. >> */ >> #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. Agree. will reword. >> + 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 >
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |