| Message ID | 20250417124844.11143-3-agarciav@amd.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Hyperlaunch device tree for dom0 | expand |
On 17.04.2025 14:48, Alejandro Vallejo wrote: > --- /dev/null > +++ b/xen/common/domain-builder/Kconfig > @@ -0,0 +1,18 @@ > + > +menu "Domain Builder Features" > +depends on HAS_BOOT_INFO That is, what's going to further be added here will not ... > +config DOMAIN_BUILDER ...depend on this, but just on HAS_BOOT_INFO? Seems not very likely, but I'll be looking forward to learn what the plans are. Also, if the entire contents here is to depend on HAS_BOOT_INFO, can't the "source" line pulling in this Kconfig be put inside "if HAS_BOOT_INFO"? That would centralize definition and use of that symbol to a single file. > + bool "Domain builder (UNSUPPORTED)" if UNSUPPORTED > + select LIBFDT > + help > + Xen has a built-in mechanisms to automatically construct domains > + (like dom0) during the boot phase. The domain builder is an enhanced > + form of that mechanism to enable constructing predefined domains > + described on a flattened device tree. I'm not a native speaker, but (perhaps because of that) "on" here reads odd. More logical to me would be "by" or "via". Jan
On 2025-04-17 11:00, Jan Beulich wrote: > On 17.04.2025 14:48, Alejandro Vallejo wrote: >> --- /dev/null >> +++ b/xen/common/domain-builder/Kconfig >> + bool "Domain builder (UNSUPPORTED)" if UNSUPPORTED >> + select LIBFDT >> + help >> + Xen has a built-in mechanisms to automatically construct domains >> + (like dom0) during the boot phase. The domain builder is an enhanced >> + form of that mechanism to enable constructing predefined domains >> + described on a flattened device tree. > > I'm not a native speaker, but (perhaps because of that) "on" here reads > odd. More logical to me would be "by" or "via". Yes, "by" is better. The description is a little backwards - it should state what it is first. Maybe: Support for constructing predefined domains described by a flattened device tree. This allows constructing multiple domains at boot time instead of being limited to a single dom0. Regards, Jason
On Thu Apr 17, 2025 at 4:00 PM BST, Jan Beulich wrote: > On 17.04.2025 14:48, Alejandro Vallejo wrote: >> --- /dev/null >> +++ b/xen/common/domain-builder/Kconfig >> @@ -0,0 +1,18 @@ >> + >> +menu "Domain Builder Features" >> +depends on HAS_BOOT_INFO > > That is, what's going to further be added here will not ... > >> +config DOMAIN_BUILDER > > ...depend on this, but just on HAS_BOOT_INFO? Seems not very likely, but > I'll be looking forward to learn what the plans are. CONFIG_HAS_BOOT_INFO has nothing to do with future plans. The domain builder is tightly integrated with the boot_info infrastructure and cannot be used (or linked) unless the arch-specific definitions are present. It cannot function without it. And this movement from arch/ to common/ forces this new Kconfig to gate core.c on boot_info existing (because it's in asm/bootinfo.h atm). I _COULD_ also move the boot_info elsewhere, but without a drive to actually use it, that seems a bit pointless. HAS_BOOT_INFO && !DOMAIN_BUILDER still links core.c, because that contains the common initialiser for boot_info. > > Also, if the entire contents here is to depend on HAS_BOOT_INFO, can't > the "source" line pulling in this Kconfig be put inside "if HAS_BOOT_INFO"? > That would centralize definition and use of that symbol to a single file. Sure. > >> + bool "Domain builder (UNSUPPORTED)" if UNSUPPORTED >> + select LIBFDT >> + help >> + Xen has a built-in mechanisms to automatically construct domains >> + (like dom0) during the boot phase. The domain builder is an enhanced >> + form of that mechanism to enable constructing predefined domains >> + described on a flattened device tree. > > I'm not a native speaker, but (perhaps because of that) "on" here reads > odd. More logical to me would be "by" or "via". > > Jan Yes, you're right. I just felt the previous help wasn't very helpful unless you knew in advance what you were toggling. Jason's more concrete suggestion in the following reply sounds reasonable too, so I'll just copy that on resend. Cheers, Alejandro
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index de2fa37f08..67de2decc5 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -15,6 +15,7 @@ config X86 select FUNCTION_ALIGNMENT_16B select GENERIC_BUG_FRAME select HAS_ALTERNATIVE + select HAS_BOOT_INFO select HAS_COMPAT select HAS_CPUFREQ select HAS_DIT diff --git a/xen/common/Kconfig b/xen/common/Kconfig index be28060716..5c9d4eb3ab 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -67,6 +67,9 @@ config GENERIC_BUG_FRAME config HAS_ALTERNATIVE bool +config HAS_BOOT_INFO + bool + config HAS_COMPAT bool @@ -144,6 +147,8 @@ config STATIC_MEMORY If unsure, say N. +source "common/domain-builder/Kconfig" + menu "Speculative hardening" config INDIRECT_THUNK diff --git a/xen/common/domain-builder/Kconfig b/xen/common/domain-builder/Kconfig new file mode 100644 index 0000000000..5b137e4c2b --- /dev/null +++ b/xen/common/domain-builder/Kconfig @@ -0,0 +1,18 @@ + +menu "Domain Builder Features" +depends on HAS_BOOT_INFO + +config DOMAIN_BUILDER + bool "Domain builder (UNSUPPORTED)" if UNSUPPORTED + select LIBFDT + help + Xen has a built-in mechanisms to automatically construct domains + (like dom0) during the boot phase. The domain builder is an enhanced + form of that mechanism to enable constructing predefined domains + described on a flattened device tree. + + This feature is currently experimental. + + If unsure, say N. + +endmenu