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.
Requires "unsupported" for the time being until all required patches
make it through.
Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
---
xen/arch/x86/Kconfig | 1 +
xen/common/Kconfig | 12 +++++++-----
xen/common/device-tree/Makefile | 2 +-
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 752d5141bb..cb4f9a834b 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -18,6 +18,7 @@ config X86
select HAS_COMPAT
select HAS_CPUFREQ
select HAS_DIT
+ select HAS_DOM0LESS
select HAS_EHCI
select HAS_EX_TABLE
select HAS_FAST_MULTIPLY
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 2baa4221fd..5118ea7453 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -13,15 +13,17 @@ config CORE_PARKING
depends on NR_CPUS > 1
config DOM0LESS_BOOT
- bool "Dom0less boot support" if EXPERT
+ bool "Dom0less boot support" if EXPERT && (!X86 || UNSUPPORTED)
select LIBFDT
- depends on HAS_DOM0LESS && HAS_DEVICE_TREE && DOMAIN_BUILD_HELPERS
- default y
+ depends on HAS_DOM0LESS && (X86 || (HAS_DEVICE_TREE && DOMAIN_BUILD_HELPERS))
+ default y if !X86
help
Dom0less boot support enables Xen to create and start domU guests during
Xen boot without the need of a control domain (Dom0), which could be
present anyway.
+ If unsure on x86, say N.
+
config DOMAIN_BUILD_HELPERS
bool
@@ -155,7 +157,7 @@ config NUMA
config STATIC_MEMORY
bool "Static Allocation Support (UNSUPPORTED)" if UNSUPPORTED
- depends on DOM0LESS_BOOT
+ depends on HAS_DEVICE_TREE && DOM0LESS_BOOT
help
Static Allocation refers to system or sub-system(domains) for
which memory areas are pre-defined by configuration using physical
@@ -174,7 +176,7 @@ config STATIC_SHM
config STATIC_EVTCHN
bool "Static event channel support on a dom0less system"
- depends on DOM0LESS_BOOT
+ depends on HAS_DEVICE_TREE && DOM0LESS_BOOT
default y
help
This option enables establishing static event channel communication
diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index cc56f42df9..f5410e685b 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -3,7 +3,7 @@ obj-$(CONFIG_HAS_DEVICE_TREE) += bootinfo-fdt.init.o
obj-$(CONFIG_HAS_DEVICE_TREE) += bootinfo.init.o
obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree.o
obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.init.o
-obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.init.o
+obj-$(filter-out $(CONFIG_X86),$(CONFIG_DOM0LESS_BOOT)) += dom0less-build.init.o
obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o
obj-$(CONFIG_HAS_DEVICE_TREE) += intc.o
obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o
--
2.43.0Hi, 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? 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. Cheers, -- Julien Grall
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
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
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.
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 >
On 13.06.2025 17: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. Which then is grossly misleading: x86 also ought to select HAS_DEVICE_TREE if it wants to use that machinery. Instead of theis an the previous patch, I think what we need is a new Kconfig setting to control the use of dom0less-build.c. Jan
On Mon Jun 16, 2025 at 8:59 AM CEST, Jan Beulich wrote: > On 13.06.2025 17: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. > > Which then is grossly misleading: x86 also ought to select HAS_DEVICE_TREE > if it wants to use that machinery. Instead of theis an the previous patch, It wants to use a _subset_. I can't use the full machinery. > I think what we need is a new Kconfig setting to control the use of > dom0less-build.c. > > Jan It's not just dom0less-build.c. It's critical to avoid parsing device_t's during the unflatten procedure (which is the few lines compiled out with ifdef CONFIG_DEVICE_TREE). Renaming CONFIG_HAS_DEVICE_TREE to CONFIG_HAS_PLATFORM_DT (with a suitable `help` message for clarity, even though it would always be enabled) should help clarify things. Does that sound reasonable? Cheers, Alejandro
On 16.06.2025 16:12, Alejandro Vallejo wrote: > On Mon Jun 16, 2025 at 8:59 AM CEST, Jan Beulich wrote: >> On 13.06.2025 17: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. >> >> Which then is grossly misleading: x86 also ought to select HAS_DEVICE_TREE >> if it wants to use that machinery. Instead of theis an the previous patch, > > It wants to use a _subset_. I can't use the full machinery. > >> I think what we need is a new Kconfig setting to control the use of >> dom0less-build.c. > > It's not just dom0less-build.c. It's critical to avoid parsing device_t's > during the unflatten procedure (which is the few lines compiled out with > ifdef CONFIG_DEVICE_TREE). > > Renaming CONFIG_HAS_DEVICE_TREE to CONFIG_HAS_PLATFORM_DT (with a suitable > `help` message for clarity, even though it would always be enabled) should > help clarify things. > > Does that sound reasonable? Perhaps. The main input has to come from DT maintainers, though. Jan
On Fri, 13 Jun 2025, 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. > > Requires "unsupported" for the time being until all required patches > make it through. > > Signed-off-by: Alejandro Vallejo <agarciav@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
© 2016 - 2025 Red Hat, Inc.