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

[Oleksii Moisieiev <Oleksii_Moisieiev@epam.com>]

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