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

[Alejandro Vallejo <agarciav@amd.com>]

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.

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

Cheers,
Alejandro