On Mon Jun 23, 2025 at 9:39 AM CEST, Jan Beulich wrote: > On 20.06.2025 20:28, Alejandro Vallejo wrote: >> Moving forward the idea is for there to be: >> 1. Basic DT support: used by dom0less/hyperlaunch. >> 2. Full DT support: used for device discovery and HW setup. >> >> Rename HAS_DEVICE_TREE to HAS_DEVICE_TREE_DISCOVERY to describe (2), while >> DOM0LESS_BOOT is left to describe (1). > > Considering hyperlaunch this feels wrong to me. Did you consider splitting > HAS_DEVICE_TREE into HAS_DEVICE_TREE_PARSE and HAS_DEVICE_TREE_DISCOVERY, > as I suggested on the committers call? You weren't there, but Stefano said > he was taking notes.
Some might've been lost is transit, I admit. I don't remember hearing about a HAS_DEVICE_TREE_PARSE, but it might've very well been me being spotty when syncing with Stefano. Having a special HAS_DEVICE_TREE_PARSE doesn't seem very helpful, as every arch would have it set. I'd definitely like for the "enable support to boot several predefined domains from DTB descriptions" to be a single option for both dom0less and hyperlaunch. And be selectable rather than unconditionally selected And ideally move towards a future in which both dom0less and hyperlaunch are one and the same. I can do an early rename s/HAS_DOM0LESS/HAS_PREDEFINED_DOMAINS and s/ DOM0LESS_BOOT/BOOT_PREDEFINED_DOMAINS/ if that helps. I was waiting to do so until x86 gains the ability to boot off a DTB to avoid having help messages describing things not yet on the tree. > >> --- a/xen/common/Kconfig >> +++ b/xen/common/Kconfig >> @@ -14,7 +14,7 @@ config CORE_PARKING >> >> config DOM0LESS_BOOT >> bool "Dom0less boot support" if EXPERT >> - depends on HAS_DOM0LESS && HAS_DEVICE_TREE && DOMAIN_BUILD_HELPERS >> + depends on HAS_DOM0LESS && HAS_DEVICE_TREE_DISCOVERY && >> DOMAIN_BUILD_HELPERS >> default y >> help >> Dom0less boot support enables Xen to create and start domU guests >> during >> @@ -85,7 +85,7 @@ config HAS_ALTERNATIVE >> config HAS_COMPAT >> bool >> >> -config HAS_DEVICE_TREE >> +config HAS_DEVICE_TREE_DISCOVERY >> bool >> select LIBFDT > > This select imo ought to move to HAS_DEVICE_TREE_PARSE, unless I misunderstand > what LIBFDT covers. Doing so would preclude compiling it out on x86 when hyperlaunch is not there. LIBFDT is very much essential on arm/riscv/ppc, but not so on x86. > >> --- a/xen/common/Makefile >> +++ b/xen/common/Makefile >> @@ -6,9 +6,9 @@ obj-$(CONFIG_HYPFS_CONFIG) += config_data.o >> obj-$(CONFIG_CORE_PARKING) += core_parking.o >> obj-y += cpu.o >> obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o >> -obj-$(CONFIG_HAS_DEVICE_TREE) += device.o >> +obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += device.o >> obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device.o >> -obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree/ >> +obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += device-tree/ > > Here I'm less certain - is everything in that subdir truly "discovery" > related? The non-discovery related parts are quite entangled with the discovery ones. In time, I'll want to move an untangled dom0less/hyperlaunch subset onto a separate predef-doms/ folder iff all of it starts using LIBFDT rather than unflattened DTs, but that's a future endavour. There's also all of bootinfo, which is not discovery related, but is used ATM exclusively by arches doing discovery. > >> --- a/xen/common/sched/Kconfig >> +++ b/xen/common/sched/Kconfig >> @@ -67,7 +67,7 @@ endmenu >> >> config BOOT_TIME_CPUPOOLS >> bool "Create cpupools at boot time" >> - depends on HAS_DEVICE_TREE >> + depends on HAS_DEVICE_TREE_DISCOVERY >> help >> Creates cpupools during boot time and assigns cpus to them. Cpupools >> options can be specified in the device tree. > > This similarly looks wrong to me. Whether to create CPU pools is purely a > Xen-internal software thing, isn't it? > > Jan In principle, it should be HAS_DOM0LESS and likely will be later when I hook it for x86. I was waiting for x86 needing such a change to use the binding. Would you rather have the change done now? Cheers, Alejandro
