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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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, but
only ARM and RISC-V would have CONFIG_DT_DEVICE_DISCOVERY.


> > Note I don't particularly care if you don't want to use it on x86. 
> > However, the argument provided is lacking some details... This will be 
> > useful in the future if someone thinks about consolidating the two.
> 
> I very definitely will want it all unified, but I'm working one elephant at
> a time.

+1