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

[Oleksii Moisieiev <Oleksii_Moisieiev@xxxxxxxx>]

Hi Jan,

Thanks for the review. I'm preparing v6 right now. My plans for the 
changes are outlined below.

On 05/10/2026 11:52, Jan Beulich wrote:
> 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 ...
For v6, I'm going to describe this as a common option for legacy Dom0
boot, with Arm implementing the code exclusion initially. My immediate
use case is an Arm deployment where guests are launched through
dom0less and legacy Dom0 boot is not needed. I'm going to clarify that
this use case motivates the initial Arm implementation, rather than
make the interface Arm-specific. Is that scope OK?
>> 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?
In the staging branch RISC-V's start_xen() does not have a legacy Dom0 
construction path.
I'm therefore going to leave HAS_DOM0 unselected on RISC-V and explain
that selection should accompany implementation of legacy Dom0 boot.
Its existing HAS_DOM0LESS selection does not provide that path.
Does it sounds ok to you?
>> 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.
Thanks for taking another look. Since v6 will change the x86 prompt and
the handling of the common Dom0 options, I'm going to leave the earlier
Acked-by out pending confirmation that it still applies.
>> --- 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'm going to limit the scope to excluding legacy Dom0 construction and
its private boot options. I'm also going to exclude the additional
Dom0-only memory, SVE and cache-coloring code identified by Michal, and
make Arm ACPI depend on DOM0_BOOT. Shared domain construction will
remain, since dom0less hardware domains also use it. I'm going to remove
the claim that this eliminates all unreachable code or establishes
MISRA compliance.

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

I checked the case with DOM0_BOOT=n. create_domUs() still calls
set_xs_domain() for a dom0less domain with XEN_DOMCTL_CDF_xs_domain set.
Similarly, construct_domU() calls construct_hwdom() for a hardware
domain.
>> --- 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".
I'm going to use Michal's proposed sequence: check is_dom0less_mode()
once, otherwise create Dom0 if DOM0_BOOT is enabled, otherwise panic.
This removes the extra braces and the repeated detection.
>> --- 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.)


I'm going to keep the option in common Kconfig, with Arm and x86
selecting HAS_DOM0, and remove !X86 from the expert prompt. I'm also
going to explain in the help text and commit message that implementing
the option on x86 remains a TODO, potentially as part of Hyperlaunch.

With this revision, x86 will still build and boot legacy Dom0 even when
DOM0_BOOT=n. I'm going to preserve its DOM0_MEM setting and dom0
command-line parser while that remains the case.

> Jan