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(-)
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@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)
*/
#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");
+ }
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
+ manage domU guests using the Xen toolstack with provided configurations.
+
config DOMAIN_BUILD_HELPERS
bool
@@ -95,6 +103,9 @@ config HAS_DOM0LESS
config HAS_DIT # Data Independent Timing
bool
+config HAS_DOM0
+ bool
+
config HAS_EX_TABLE
bool
--
2.34.1On 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@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. I question the way changes were made. I don't see the value of ... > --- 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 ... this, as it has no effect ... > --- 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 ... here due to the further dependencies, and .., > + default y ... hence this option still doesn't end up constant-Y for x86. Jan
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@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
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.
>>
[snip]
>>
>> 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 just wanted to add that I have only guarded dom0_max_vcpus because it
is used by the create_dom0() function. The other parameters are used in
functions that are also reused by dom0less builds.
>> */
>> #define DOM0_FDT_EXTRA_SIZE (128 + sizeof(struct fdt_reserve_entry))
>>
>> +#ifdef CONFIG_DOM0_BOOT
>> unsigned int __init dom0_max_vcpus(void)
>>
[snip]
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@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?
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
>
On Mon, Jul 28, 2025 at 05:07:30PM +0000, 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@epam.com> > > --- > > --- > 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(-) I think there should be changes in include/xen/domain.h and arch/arm/include/asm/setup.h to compile out declarations of dom0_max_vcpus() and create_dom0() under new CONFIG_DOM0_BOOT. I would also define default implementations using ASSERT_UNREACHABLE() under #ifndef CONFIG_DOM0_BOOT.
On 28.07.2025 23:28, dmkhn@proton.me wrote: > On Mon, Jul 28, 2025 at 05:07:30PM +0000, 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@epam.com> >> >> --- >> >> --- >> 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(-) > > I think there should be changes in > include/xen/domain.h > and > arch/arm/include/asm/setup.h > to compile out declarations of dom0_max_vcpus() and create_dom0() under new > CONFIG_DOM0_BOOT. Adding #ifdef-ary just to hide declarations is often merely adding clutter, without providing a clear benefit. I didn't check in this case, but I think when making such a request you want to clarify what the gains would be of adding more #ifdef. Jan
On Tue, Jul 29, 2025 at 10:20:54AM +0200, Jan Beulich wrote:
> On 28.07.2025 23:28, dmkhn@proton.me wrote:
> > On Mon, Jul 28, 2025 at 05:07:30PM +0000, 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@epam.com>
> >>
> >> ---
> >>
> >> ---
> >> 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(-)
> >
> > I think there should be changes in
> > include/xen/domain.h
> > and
> > arch/arm/include/asm/setup.h
> > to compile out declarations of dom0_max_vcpus() and create_dom0() under new
> > CONFIG_DOM0_BOOT.
>
> Adding #ifdef-ary just to hide declarations is often merely adding clutter,
> without providing a clear benefit. I didn't check in this case, but I think
> when making such a request you want to clarify what the gains would be of
> adding more #ifdef.
re: clutter: fully agree.
I was thinking about this following code where ifdef-ery may be needed:
+ if ( IS_ENABLED(CONFIG_DOM0_BOOT) && !is_dom0less_mode() )
+ {
+ /* Create initial domain 0. */
create_dom0();
+ }
But looks like compiler is correctly throwing away create_dom0() call.
>
> Jan
On 30/07/2025 01:10, dmkhn@proton.me wrote:
> On Tue, Jul 29, 2025 at 10:20:54AM +0200, Jan Beulich wrote:
>> On 28.07.2025 23:28, dmkhn@proton.me wrote:
>>> On Mon, Jul 28, 2025 at 05:07:30PM +0000, 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@epam.com>
>>>>
>>>> ---
>>>>
>>>> ---
>>>> 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(-)
>>> I think there should be changes in
>>> include/xen/domain.h
>>> and
>>> arch/arm/include/asm/setup.h
>>> to compile out declarations of dom0_max_vcpus() and create_dom0() under new
>>> CONFIG_DOM0_BOOT.
>> Adding #ifdef-ary just to hide declarations is often merely adding clutter,
>> without providing a clear benefit. I didn't check in this case, but I think
>> when making such a request you want to clarify what the gains would be of
>> adding more #ifdef.
> re: clutter: fully agree.
>
> I was thinking about this following code where ifdef-ery may be needed:
>
> + if ( IS_ENABLED(CONFIG_DOM0_BOOT) && !is_dom0less_mode() )
> + {
> + /* Create initial domain 0. */
> create_dom0();
> + }
>
> But looks like compiler is correctly throwing away create_dom0() call.
Yes, it is. It is preferable to use IS_ENABLED in if statements whenever
possible.
>> Jan
© 2016 - 2025 Red Hat, Inc.