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 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. 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.

>
>> --- 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.

>
>> --- a/xen/common/Makefile
>> +++ b/xen/common/Makefile
>> @@ -6,9 +6,9 @@ obj-$(CONFIG_HYPFS_CONFIG) += config_data.o
>>  obj-$(CONFIG_CORE_PARKING) += core_parking.o
>>  obj-y += cpu.o
>>  obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o
>> -obj-$(CONFIG_HAS_DEVICE_TREE) += device.o
>> +obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += device.o
>>  obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device.o
>> -obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree/
>> +obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += device-tree/
>
> Here I'm less certain - is everything in that subdir truly "discovery" 
> related?

The non-discovery related parts are quite entangled with the discovery ones. In
time, I'll want to move an untangled dom0less/hyperlaunch subset onto a separate
predef-doms/ folder iff all of it starts using LIBFDT rather than unflattened
DTs, but that's a future endavour.

There's also all of bootinfo, which is not discovery related, but is used ATM
exclusively by arches doing discovery.

>
>> --- 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?
>
> Jan

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?

Cheers,
Alejandro