[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


  • To: "Orzel, Michal" <michal.orzel@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Oleksii Moisieiev <Oleksii_Moisieiev@xxxxxxxx>
  • Date: Mon, 4 Aug 2025 14:05:30 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8RhVxxBH7o+C8vn1hh6QJ+PLQ8ZNuEZgESJG6mHsVA4=; b=qktHHdUxXO50ZSGHzNIeYCBASFHkzm7m+gt62kYttouQ58c7Y5MxZlPdb1rlfYGSp1g3VO3AbjCKmqqHlwwN1/0G/lorPXJkaKqcNhN1g6y4PvQFf2nqUWkx9EmyE0Nduo+hHQF2YSsumh3FyZgleSzs5pUDdyKVkAYOBYzk3N0frXei0wrCBJS037Z2oUQr0SQt7Q612lMK/GS6e9X2XoTl5+eXUkaa8MymOCmkFmAOnkG2V1BEPckFre/MulJ3VTksDjn492pcaRKwSOkrFjV1SfMvDokF6OSD5J+9fdsNBFoDY2zA8ZCQjofmvDu/UQIJnRERVpZN/K368s+BuQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=yJX86y7O15VdeoAqjzLqUqv+ykvOppDreUO1vQwPRLk/9bXFcE02szUG6AaGFoC/P6V3hyAgAH0waymTswsNYSKzmO5sJo+VUqk7iRWaAh31C6WhVdzU7SSU6LvhB3n5dYZnCtRyg1X5lrgE3P6LsSLTeFgca8fm0ApC7i5UjGa9bSXpOUwnQAqpklmfC/O1lgLnv72ZzzKFDF6DBBsZrSirYs+xkWzeJQPy6lrCCJHLwniM32e/bMJf8Q32EW69Y9cs+SehoJoQF7Gd4DUGtc1C0wOWUMNTHDETN9BMfjKQnuNMNzWzVw9iF1sG1+RyOrqPAXLx/setNPRSaVF7bQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Julien Grall <julien@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Oleksandr Tyshchenko <Oleksandr_Tyshchenko@xxxxxxxx>
  • Delivery-date: Mon, 04 Aug 2025 14:05:36 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHb/+IacHiE2y5puk2LQertSkS3OrRIs0MAgAneo4A=
  • Thread-topic: [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
>

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.