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

[dmkhn@xxxxxxxxx]

On Mon, Jun 16, 2025 at 04:39:28PM -0700, 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

Perhaps, shorter name like CONFIG_DT will be satisfactory? (instead of
CONFIG_DT_DEVICE_DISCOVERY and 'similar' convention to existing CONFIG_ACPI)

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