Re: [PATCH v4 10/12] xen: Rename CONFIG_HAS_DEVICE_TREE to CONFIG_HAS_DEVICE_TREE_DISCOVERY

[Alejandro Vallejo <agarciav@xxxxxxx>]

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