Re: [PATCH v3 14/14] kconfig: Allow x86 to pick CONFIG_DOM0LESS_BOOT

[Jan Beulich <jbeulich@xxxxxxxx>]

On 17.06.2025 01:39, Stefano Stabellini wrote:
> On Mon, 16 Jun 2025, Alejandro Vallejo wrote:
>> On Mon Jun 16, 2025 at 10:00 AM CEST, Julien Grall wrote:
>>> Hi,
>>>
>>> On 13/06/2025 16:13, Alejandro Vallejo wrote:
>>>> Without picking CONFIG_HAS_DEVICE_TREE.
>>>>
>>>> In order to do that. Allow CONFIG_DOM0LESS_BOOT to enable a subset
>>>> of the common/device-tree/ directory. 
>>>  > x86 doesn't want dom0less-build.c,> as that's tightly integrated 
>>> still to the ARM way of building domains.
>>>
>>> I don't understand this argument. dom0less-build.c was moved to common 
>>> and it will soon be used by RISC-V. This raises the question what's so 
>>> special with x86?
>>
>> That's 2 separate matters:
>>
>>   1. dom0less-build.c not being compiled in.
>>   2. CONFIG_DOM0LESS_BOOT enabling use of DT code without 
>> CONFIG_HAS_DEVICE_TREE.
>>
>> (1) is a matter of not wanting to boil the ocean upfront. The way x86 and
>> everyone else build domains is just different and duplicated in non-trivially
>> consolidable ways. The goal here is to enable the domain builders in any arch
>> to use the same backbone. I don't want to go the extra mile just yet to unify
>> domain construction (though in time I will want to).
>>
>> (2) has to do with compiling OUT things I really cannot have around. Anything
>> involving devices described in a DT must not exist on x86, because it has no
>> concept of a "struct device".
>>
>> My intent is/was to repurpose CONFIG_HAS_DEVICE_TREE to mean "this hypervisor
>> goes on a platform that gives a platform-describing DT". On x86 that's given 
>> by
>> DSDT/SSDTs with ACPI.
> 
> Alejandro is suggesting two levels of Device Tree support:
> 
> - full DT support, including device discovery via DT
> - minimal DT support, for the dom0less/hyperlaunch configuration
> 
> Reading this series, it looks reasonable to me, at least as a stepping
> stone. I think it is expected that the kind of DT support needed by an
> architecture like ARM or RISC-V is different from the one needed by an
> architecture like x86. Of course we might be able to align things even
> more in the future but as of today I think it is reasonable to
> distinguish between the two.
> 
> That said, we might want to consider renaming or changing the kconfig
> options. For instance:
> 
> - CONFIG_HAS_DEVICE_TREE -> enable minimal DT support
> - CONFIG_DT_DEVICE_DISCOVERY -> device discovery via DT
> 
> In this model, all architectures would have CONFIG_HAS_DEVICE_TREE,

In which case - do we still need HAS_DEVICE_TREE?

Jan

> but
> only ARM and RISC-V would have CONFIG_DT_DEVICE_DISCOVERY.