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

[Alejandro Vallejo <agarciav@amd.com>]

On Mon Jun 23, 2025 at 4:26 PM CEST, Jan Beulich wrote:
> On 23.06.2025 16:19, Alejandro Vallejo wrote:
>> 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?
>
> Yes. Except that in the last sentence of the previous paragraph: What's "the
> tree"?

By "the tree", I meant the hypervisor tree. I just mean that Kconfig would use
DEVICEC_TREE_PARSE for selection purposes and the code would ifdef based on
DEVICE_TREE_PARSE rather than DOM0LESS_BOOT rather than using the latter as a
proxy.  

> And in device_tree/ wouldn't we end up with unreachable code on x86
> this way (the parts that are needed only by HAS_DEVICE_TREE_DISCOVERY)?

They'd be compiled-out, just as they are now gated on HAS_DEVICE_TREE_DISCOVERY on
this patch. device-tree/ as a whole would be gated by DEVICE_TREE_PARSE, and each
individual file inside might optionally be gated by stronger options.

Cheers,
Alejandro