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

[Jan Beulich <jbeulich@xxxxxxxx>]

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