On Mon Jun 23, 2025 at 3:44 PM CEST, Jan Beulich wrote: > 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.
It's about x86 using device_tree/ for hyperlaunch. x86 is the single user that doesn't need (2) at all. In the x86 case the same selector that picks > >> 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. Ok, how about turning it on its head? Seems like we're in agreement with HAS_DEVICE_TREE_DISCOVERY for Full DT support. There could be a DEVICE_TREE_PARSE (no HAS_) that's selected by HAS_DEVICE_TREE_DISCOVERY and DOM0LESS_BOOT. This allows x86 to deselect it by not picking DOM0LESS_BOOT. Note that x86 cannot select DOM0LESS_BOOT yet, but that's how it'd compile-in hyperlaunch. In the meantime, the tree depends on DEVICE_TREE_PARSE instead and device_tree/ is gated by DEVICE_TREE_PARSE only. Sounds better? > >>>> --- 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. DOM0LESS_BOOT would do so once required. In the proposal above that'd be selected by DEVICE_TREE_PARSE, which would be selected by DOM0LESS_BOOT. > >>>> --- 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 I think this latest proposal addresses the concern. Let me know what you think. Cheers, Alejandro
