On 23.06.2025 15:11, Alejandro Vallejo wrote: > 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.
Hmm, yes, we don't want or need that. But then what's option 1 about? That shouldn't be "described" by DOM0LESS_BOOT. > 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. I have to admit that it's not clear to me if that would help. As you say, on x86 that's not a thing just yet. What I think we need to aim for is to not leave the tree in a state that's more confusing than anything else. Even if later (which may be much later) things would get tidied again. >>> --- 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. Okay, but _something_ has to select that on x86 as well, once hyperlaunch is going to need it. >>> --- 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? > > 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? See above - my main concern isn't with what is introduced early or later, but what the overall (intermediate and final) state of the tree is going to be. Jan
