* [PATCH v5 01/12] kconfig: introduce domain builder config options
2025-04-24 16:10 [PATCH v5 00/12] Hyperlaunch device tree for dom0 Alejandro Vallejo
@ 2025-04-24 16:10 ` Alejandro Vallejo
2025-04-24 16:54 ` Jason Andryuk
2025-04-24 16:10 ` [PATCH v5 02/12] common/hyperlaunch: introduce the domain builder Alejandro Vallejo
` (11 subsequent siblings)
12 siblings, 1 reply; 23+ messages in thread
From: Alejandro Vallejo @ 2025-04-24 16:10 UTC (permalink / raw)
To: xen-devel
Cc: Daniel P. Smith, Andrew Cooper, Anthony PERARD, Michal Orzel,
Jan Beulich, Julien Grall, Roger Pau Monné,
Stefano Stabellini, Alejandro Vallejo
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Hyperlaunch domain builder will be the consolidated boot time domain
building logic framework. Introduces the config option to enable this
domain builder to eventually turn on the ability to load the domain
configuration via a flattened device tree.
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
---
v5:
* Removed CONFIG_HAS_BOOT_INFO
* Reworded help message
---
xen/common/Kconfig | 2 ++
xen/common/domain-builder/Kconfig | 15 +++++++++++++++
2 files changed, 17 insertions(+)
create mode 100644 xen/common/domain-builder/Kconfig
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index be28060716..e025fbe257 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -144,6 +144,8 @@ config STATIC_MEMORY
If unsure, say N.
+source "common/domain-builder/Kconfig"
+
menu "Speculative hardening"
config INDIRECT_THUNK
diff --git a/xen/common/domain-builder/Kconfig b/xen/common/domain-builder/Kconfig
new file mode 100644
index 0000000000..44b8351af8
--- /dev/null
+++ b/xen/common/domain-builder/Kconfig
@@ -0,0 +1,15 @@
+menu "Domain Builder Features"
+
+config DOMAIN_BUILDER
+ bool "Domain builder (UNSUPPORTED)" if UNSUPPORTED && X86
+ select LIBFDT
+ help
+ Support for constructing predefined domains described by a flattened
+ device tree. This allows constructing multiple domains at boot time
+ instead of being limited to a single dom0.
+
+ This feature is currently experimental.
+
+ If unsure, say N.
+
+endmenu
--
2.43.0
^ permalink raw reply related [flat|nested] 23+ messages in thread* Re: [PATCH v5 01/12] kconfig: introduce domain builder config options
2025-04-24 16:10 ` [PATCH v5 01/12] kconfig: introduce domain builder config options Alejandro Vallejo
@ 2025-04-24 16:54 ` Jason Andryuk
2025-04-25 12:40 ` Alejandro Vallejo
0 siblings, 1 reply; 23+ messages in thread
From: Jason Andryuk @ 2025-04-24 16:54 UTC (permalink / raw)
To: Alejandro Vallejo, xen-devel
Cc: Daniel P. Smith, Andrew Cooper, Anthony PERARD, Michal Orzel,
Jan Beulich, Julien Grall, Roger Pau Monné,
Stefano Stabellini
On 2025-04-24 12:10, Alejandro Vallejo wrote:
> From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
>
> Hyperlaunch domain builder will be the consolidated boot time domain
> building logic framework. Introduces the config option to enable this
"Introduce the"
> domain builder to eventually turn on the ability to load the domain
> configuration via a flattened device tree.
>
> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
Maybe the title should be "kconfig: introduce CONFIG_DOMAIN_BUILDER" to
more directly state what is happening.
At least with the typo fixed:
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Thanks,
Jason
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v5 01/12] kconfig: introduce domain builder config options
2025-04-24 16:54 ` Jason Andryuk
@ 2025-04-25 12:40 ` Alejandro Vallejo
0 siblings, 0 replies; 23+ messages in thread
From: Alejandro Vallejo @ 2025-04-25 12:40 UTC (permalink / raw)
To: Jason Andryuk, xen-devel
Cc: Daniel P. Smith, Andrew Cooper, Anthony PERARD, Michal Orzel,
Jan Beulich, Julien Grall, Roger Pau Monné,
Stefano Stabellini
On Thu Apr 24, 2025 at 5:54 PM BST, Jason Andryuk wrote:
> On 2025-04-24 12:10, Alejandro Vallejo wrote:
>> From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
>>
>> Hyperlaunch domain builder will be the consolidated boot time domain
>> building logic framework. Introduces the config option to enable this
>
> "Introduce the"
>
>> domain builder to eventually turn on the ability to load the domain
>> configuration via a flattened device tree.
>>
>> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
>> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
>
> Maybe the title should be "kconfig: introduce CONFIG_DOMAIN_BUILDER" to
> more directly state what is happening.
Sounds good.
>
> At least with the typo fixed:
>
> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Cheers,
Alejandro
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH v5 02/12] common/hyperlaunch: introduce the domain builder
2025-04-24 16:10 [PATCH v5 00/12] Hyperlaunch device tree for dom0 Alejandro Vallejo
2025-04-24 16:10 ` [PATCH v5 01/12] kconfig: introduce domain builder config options Alejandro Vallejo
@ 2025-04-24 16:10 ` Alejandro Vallejo
2025-04-24 16:10 ` [PATCH v5 03/12] x86/hyperlaunch: initial support for hyperlaunch device tree Alejandro Vallejo
` (10 subsequent siblings)
12 siblings, 0 replies; 23+ messages in thread
From: Alejandro Vallejo @ 2025-04-24 16:10 UTC (permalink / raw)
To: xen-devel
Cc: Daniel P. Smith, Jan Beulich, Andrew Cooper, Roger Pau Monné,
Anthony PERARD, Michal Orzel, Julien Grall, Stefano Stabellini,
Jason Andryuk, Alejandro Vallejo
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Introduce the domain builder which is capable of consuming a device tree as the
first boot module. If it finds a device tree as the first boot module, it will
set its type to BOOTMOD_FDT. This change only detects the boot module and
continues to boot with slight change to the boot convention that the dom0
kernel is no longer first boot module but is the second.
No functional change intended.
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
---
v5:
* Decoupled core.c from !CONFIG_DOMAIN_BUILDER
* builder_init() now returns an enumerated type of the kind of FDT it
found. If no FDT is found, then initialisation happens inline in
setup.c
* Refactored the switch in core.c to operate on an enumerated type instead
* This has knock-on effects on the helper
* Moved hyperlaunch detection path to the following patch
---
xen/arch/x86/include/asm/bootinfo.h | 3 ++
xen/arch/x86/setup.c | 19 ++++++++----
xen/common/Makefile | 1 +
xen/common/domain-builder/Makefile | 2 ++
xen/common/domain-builder/core.c | 45 +++++++++++++++++++++++++++++
xen/common/domain-builder/fdt.c | 39 +++++++++++++++++++++++++
xen/common/domain-builder/fdt.h | 14 +++++++++
xen/include/xen/domain-builder.h | 29 +++++++++++++++++++
8 files changed, 146 insertions(+), 6 deletions(-)
create mode 100644 xen/common/domain-builder/Makefile
create mode 100644 xen/common/domain-builder/core.c
create mode 100644 xen/common/domain-builder/fdt.c
create mode 100644 xen/common/domain-builder/fdt.h
create mode 100644 xen/include/xen/domain-builder.h
diff --git a/xen/arch/x86/include/asm/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h
index 3afc214c17..82c2650fcf 100644
--- a/xen/arch/x86/include/asm/bootinfo.h
+++ b/xen/arch/x86/include/asm/bootinfo.h
@@ -27,6 +27,7 @@ enum bootmod_type {
BOOTMOD_RAMDISK,
BOOTMOD_MICROCODE,
BOOTMOD_XSM_POLICY,
+ BOOTMOD_FDT,
};
struct boot_module {
@@ -80,6 +81,8 @@ struct boot_info {
paddr_t memmap_addr;
size_t memmap_length;
+ bool hyperlaunch_enabled;
+
unsigned int nr_modules;
struct boot_module mods[MAX_NR_BOOTMODS + 1];
struct boot_domain domains[MAX_NR_BOOTDOMS];
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index cf1ea040dd..bd13d9d196 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -5,6 +5,7 @@
#include <xen/cpuidle.h>
#include <xen/dmi.h>
#include <xen/domain.h>
+#include <xen/domain-builder.h>
#include <xen/domain_page.h>
#include <xen/efi.h>
#include <xen/err.h>
@@ -1283,9 +1284,14 @@ void asmlinkage __init noreturn __start_xen(void)
bi->nr_modules);
}
- /* Dom0 kernel is always first */
- bi->mods[0].type = BOOTMOD_KERNEL;
- bi->domains[0].kernel = &bi->mods[0];
+ if ( builder_init(bi) == FDT_KIND_NONE )
+ {
+ /* Find first unknown boot module to use as dom0 kernel */
+ i = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
+ bi->mods[i].type = BOOTMOD_KERNEL;
+ bi->domains[0].kernel = &bi->mods[i];
+ bi->hyperlaunch_enabled = false;
+ }
if ( pvh_boot )
{
@@ -1468,8 +1474,9 @@ void asmlinkage __init noreturn __start_xen(void)
xen->size = __2M_rwdata_end - _stext;
}
- bi->mods[0].headroom =
- bzimage_headroom(bootstrap_map_bm(&bi->mods[0]), bi->mods[0].size);
+ bi->domains[0].kernel->headroom =
+ bzimage_headroom(bootstrap_map_bm(bi->domains[0].kernel),
+ bi->domains[0].kernel->size);
bootstrap_unmap();
#ifndef highmem_start
@@ -1593,7 +1600,7 @@ void asmlinkage __init noreturn __start_xen(void)
#endif
}
- if ( bi->mods[0].headroom && !bi->mods[0].relocated )
+ if ( bi->domains[0].kernel->headroom && !bi->domains[0].kernel->relocated )
panic("Not enough memory to relocate the dom0 kernel image\n");
for ( i = 0; i < bi->nr_modules; ++i )
{
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 98f0873056..e42af71e3f 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -11,6 +11,7 @@ obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device.o
obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree/
obj-$(CONFIG_IOREQ_SERVER) += dm.o
obj-y += domain.o
+obj-$(CONFIG_DOMAIN_BUILDER) += domain-builder/
obj-y += event_2l.o
obj-y += event_channel.o
obj-$(CONFIG_EVTCHN_FIFO) += event_fifo.o
diff --git a/xen/common/domain-builder/Makefile b/xen/common/domain-builder/Makefile
new file mode 100644
index 0000000000..bfd2f6267e
--- /dev/null
+++ b/xen/common/domain-builder/Makefile
@@ -0,0 +1,2 @@
+obj-y += fdt.init.o
+obj-y += core.init.o
diff --git a/xen/common/domain-builder/core.c b/xen/common/domain-builder/core.c
new file mode 100644
index 0000000000..fdc13aee40
--- /dev/null
+++ b/xen/common/domain-builder/core.c
@@ -0,0 +1,45 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2024, Apertus Solutions, LLC
+ */
+#include <xen/bug.h>
+#include <xen/err.h>
+#include <xen/init.h>
+#include <xen/kconfig.h>
+#include <xen/domain-builder.h>
+#include <xen/lib.h>
+
+#include <asm/bootinfo.h>
+
+#include "fdt.h"
+
+enum fdt_kind __init builder_init(struct boot_info *bi)
+{
+ enum fdt_kind kind;
+
+ bi->hyperlaunch_enabled = false;
+ switch ( (kind = detect_fdt_kind(bi)) )
+ {
+ case FDT_KIND_NONE:
+ /* No DT found */
+ return kind;
+
+ case FDT_KIND_UNKNOWN:
+ printk(XENLOG_DEBUG "DT found: non-hyperlaunch\n");
+ bi->mods[0].type = BOOTMOD_FDT;
+ return kind;
+
+ default:
+ BUG();
+ }
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/common/domain-builder/fdt.c b/xen/common/domain-builder/fdt.c
new file mode 100644
index 0000000000..708dcfcbe8
--- /dev/null
+++ b/xen/common/domain-builder/fdt.c
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2024, Apertus Solutions, LLC
+ */
+#include <xen/err.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/libfdt/libfdt.h>
+
+#include <asm/bootinfo.h>
+#include <asm/page.h>
+#include <asm/setup.h>
+
+#include "fdt.h"
+
+enum fdt_kind __init detect_fdt_kind(const struct boot_info *bi)
+{
+ enum fdt_kind kind;
+ const void *fdt = bootstrap_map_bm(&bi->mods[HYPERLAUNCH_MODULE_IDX]);
+
+ if ( !fdt || fdt_check_header(fdt) < 0 )
+ kind = FDT_KIND_NONE;
+ else
+ kind = FDT_KIND_UNKNOWN;
+
+ bootstrap_unmap();
+
+ return kind;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/common/domain-builder/fdt.h b/xen/common/domain-builder/fdt.h
new file mode 100644
index 0000000000..ed9c62631c
--- /dev/null
+++ b/xen/common/domain-builder/fdt.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __XEN_DOMAIN_BUILDER_FDT_H__
+#define __XEN_DOMAIN_BUILDER_FDT_H__
+
+#include <xen/domain-builder.h>
+
+struct boot_info;
+
+/* hyperlaunch fdt is required to be module 0 */
+#define HYPERLAUNCH_MODULE_IDX 0
+
+enum fdt_kind detect_fdt_kind(const struct boot_info *bi);
+
+#endif /* __XEN_DOMAIN_BUILDER_FDT_H__ */
diff --git a/xen/include/xen/domain-builder.h b/xen/include/xen/domain-builder.h
new file mode 100644
index 0000000000..b9702db735
--- /dev/null
+++ b/xen/include/xen/domain-builder.h
@@ -0,0 +1,29 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __XEN_DOMAIN_BUILDER_H__
+#define __XEN_DOMAIN_BUILDER_H__
+
+struct boot_info;
+
+/* Return status of builder_init(). Shows which boot mechanism was detected */
+enum fdt_kind
+{
+ /* FDT not found. Skipped builder. */
+ FDT_KIND_NONE,
+ /* Found an FDT that wasn't hyperlaunch. */
+ FDT_KIND_UNKNOWN,
+};
+
+/*
+ * Initialises `bi` if it detects a compatible FDT. Otherwise returns
+ * FDT_KIND_NONE and leaves initialisation up to the caller.
+ */
+#if IS_ENABLED(CONFIG_DOMAIN_BUILDER)
+enum fdt_kind builder_init(struct boot_info *bi);
+#else
+static inline enum fdt_kind builder_init(struct boot_info *bi)
+{
+ return FDT_KIND_NONE;
+}
+#endif /* !IS_ENABLED(CONFIG_DOMAIN_BUILDER) */
+
+#endif /* __XEN_DOMAIN_BUILDER_H__ */
--
2.43.0
^ permalink raw reply related [flat|nested] 23+ messages in thread* [PATCH v5 03/12] x86/hyperlaunch: initial support for hyperlaunch device tree
2025-04-24 16:10 [PATCH v5 00/12] Hyperlaunch device tree for dom0 Alejandro Vallejo
2025-04-24 16:10 ` [PATCH v5 01/12] kconfig: introduce domain builder config options Alejandro Vallejo
2025-04-24 16:10 ` [PATCH v5 02/12] common/hyperlaunch: introduce the domain builder Alejandro Vallejo
@ 2025-04-24 16:10 ` Alejandro Vallejo
2025-04-24 16:10 ` [PATCH v5 04/12] x86/hyperlaunch: Add helpers to locate multiboot modules Alejandro Vallejo
` (9 subsequent siblings)
12 siblings, 0 replies; 23+ messages in thread
From: Alejandro Vallejo @ 2025-04-24 16:10 UTC (permalink / raw)
To: xen-devel
Cc: Daniel P. Smith, Jan Beulich, Andrew Cooper, Roger Pau Monné,
Anthony PERARD, Michal Orzel, Julien Grall, Stefano Stabellini,
Jason Andryuk, Alejandro Vallejo
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Add the ability to detect both a formal hyperlaunch device tree or a dom0less
device tree. If the hyperlaunch device tree is found, then count the number of
domain entries, reporting an error if more than one is found.
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
---
v5:
* Turned !fdt check into a BUG_ON(). It's checked ahead of time.
---
xen/arch/x86/include/asm/bootinfo.h | 1 +
xen/common/domain-builder/core.c | 15 +++++++
xen/common/domain-builder/fdt.c | 62 +++++++++++++++++++++++++++++
xen/common/domain-builder/fdt.h | 1 +
xen/include/xen/domain-builder.h | 2 +
5 files changed, 81 insertions(+)
diff --git a/xen/arch/x86/include/asm/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h
index 82c2650fcf..1e3d582e45 100644
--- a/xen/arch/x86/include/asm/bootinfo.h
+++ b/xen/arch/x86/include/asm/bootinfo.h
@@ -84,6 +84,7 @@ struct boot_info {
bool hyperlaunch_enabled;
unsigned int nr_modules;
+ unsigned int nr_domains;
struct boot_module mods[MAX_NR_BOOTMODS + 1];
struct boot_domain domains[MAX_NR_BOOTDOMS];
};
diff --git a/xen/common/domain-builder/core.c b/xen/common/domain-builder/core.c
index fdc13aee40..0955558977 100644
--- a/xen/common/domain-builder/core.c
+++ b/xen/common/domain-builder/core.c
@@ -16,10 +16,17 @@
enum fdt_kind __init builder_init(struct boot_info *bi)
{
enum fdt_kind kind;
+ int ret;
bi->hyperlaunch_enabled = false;
switch ( (kind = detect_fdt_kind(bi)) )
{
+ case FDT_KIND_HYPERLAUNCH:
+ printk(XENLOG_DEBUG "DT found: hyperlaunch\n");
+ bi->hyperlaunch_enabled = true;
+ bi->mods[0].type = BOOTMOD_FDT;
+ break;
+
case FDT_KIND_NONE:
/* No DT found */
return kind;
@@ -32,6 +39,14 @@ enum fdt_kind __init builder_init(struct boot_info *bi)
default:
BUG();
}
+
+ printk(XENLOG_INFO "Hyperlaunch configuration:\n");
+ if ( (ret = walk_hyperlaunch_fdt(bi)) < 0 )
+ panic("Walk of device tree failed (%d)\n", ret);
+
+ printk(XENLOG_INFO " number of domains: %u\n", bi->nr_domains);
+
+ return FDT_KIND_HYPERLAUNCH;
}
/*
diff --git a/xen/common/domain-builder/fdt.c b/xen/common/domain-builder/fdt.c
index 708dcfcbe8..c1ccba39a2 100644
--- a/xen/common/domain-builder/fdt.c
+++ b/xen/common/domain-builder/fdt.c
@@ -13,6 +13,36 @@
#include "fdt.h"
+static int __init find_hyperlaunch_node(const void *fdt)
+{
+ int hv_node = fdt_path_offset(fdt, "/chosen/hypervisor");
+
+ if ( hv_node >= 0 )
+ {
+ /* Anything other than zero indicates no match */
+ if ( fdt_node_check_compatible(fdt, hv_node, "hypervisor,xen") )
+ return -ENODATA;
+
+ return hv_node;
+ }
+ else
+ {
+ /* Look for dom0less config */
+ int node, chosen_node = fdt_path_offset(fdt, "/chosen");
+
+ if ( chosen_node < 0 )
+ return -ENOENT;
+
+ fdt_for_each_subnode(node, fdt, chosen_node)
+ {
+ if ( !fdt_node_check_compatible(fdt, node, "xen,domain") )
+ return chosen_node;
+ }
+ }
+
+ return -ENODATA;
+}
+
enum fdt_kind __init detect_fdt_kind(const struct boot_info *bi)
{
enum fdt_kind kind;
@@ -20,6 +50,8 @@ enum fdt_kind __init detect_fdt_kind(const struct boot_info *bi)
if ( !fdt || fdt_check_header(fdt) < 0 )
kind = FDT_KIND_NONE;
+ else if ( find_hyperlaunch_node(fdt) >= 0 )
+ kind = FDT_KIND_HYPERLAUNCH;
else
kind = FDT_KIND_UNKNOWN;
@@ -28,6 +60,36 @@ enum fdt_kind __init detect_fdt_kind(const struct boot_info *bi)
return kind;
}
+int __init walk_hyperlaunch_fdt(struct boot_info *bi)
+{
+ int ret = 0, hv_node, node;
+ const void *fdt = bootstrap_map_bm(&bi->mods[HYPERLAUNCH_MODULE_IDX]);
+
+ BUG_ON(!fdt);
+
+ hv_node = find_hyperlaunch_node(fdt);
+ if ( hv_node < 0 )
+ {
+ ret = hv_node;
+ goto err_out;
+ }
+
+ fdt_for_each_subnode(node, fdt, hv_node)
+ {
+ if ( !fdt_node_check_compatible(fdt, node, "xen,domain") )
+ bi->nr_domains++;
+ }
+
+ /* Until multi-domain construction is added, throw an error */
+ if ( bi->nr_domains != 1 )
+ printk(XENLOG_ERR "hyperlaunch only supports dom0 construction\n");
+
+ err_out:
+ bootstrap_unmap();
+
+ return ret;
+}
+
/*
* Local variables:
* mode: C
diff --git a/xen/common/domain-builder/fdt.h b/xen/common/domain-builder/fdt.h
index ed9c62631c..826c0f01e5 100644
--- a/xen/common/domain-builder/fdt.h
+++ b/xen/common/domain-builder/fdt.h
@@ -10,5 +10,6 @@ struct boot_info;
#define HYPERLAUNCH_MODULE_IDX 0
enum fdt_kind detect_fdt_kind(const struct boot_info *bi);
+int walk_hyperlaunch_fdt(struct boot_info *bi);
#endif /* __XEN_DOMAIN_BUILDER_FDT_H__ */
diff --git a/xen/include/xen/domain-builder.h b/xen/include/xen/domain-builder.h
index b9702db735..cbb3cbea7c 100644
--- a/xen/include/xen/domain-builder.h
+++ b/xen/include/xen/domain-builder.h
@@ -9,6 +9,8 @@ enum fdt_kind
{
/* FDT not found. Skipped builder. */
FDT_KIND_NONE,
+ /* Found Hyperlaunch FDT */
+ FDT_KIND_HYPERLAUNCH,
/* Found an FDT that wasn't hyperlaunch. */
FDT_KIND_UNKNOWN,
};
--
2.43.0
^ permalink raw reply related [flat|nested] 23+ messages in thread* [PATCH v5 04/12] x86/hyperlaunch: Add helpers to locate multiboot modules
2025-04-24 16:10 [PATCH v5 00/12] Hyperlaunch device tree for dom0 Alejandro Vallejo
` (2 preceding siblings ...)
2025-04-24 16:10 ` [PATCH v5 03/12] x86/hyperlaunch: initial support for hyperlaunch device tree Alejandro Vallejo
@ 2025-04-24 16:10 ` Alejandro Vallejo
2025-04-24 16:10 ` [PATCH v5 05/12] x86/hyperlaunch: locate dom0 kernel with hyperlaunch Alejandro Vallejo
` (8 subsequent siblings)
12 siblings, 0 replies; 23+ messages in thread
From: Alejandro Vallejo @ 2025-04-24 16:10 UTC (permalink / raw)
To: xen-devel
Cc: Alejandro Vallejo, Andrew Cooper, Anthony PERARD, Michal Orzel,
Jan Beulich, Julien Grall, Roger Pau Monné,
Stefano Stabellini, Jason Andryuk
Hyperlaunch mandates either a reg or module-index DT prop on nodes that
contain `multiboot,module" under their "compatible" prop. This patch
introduces a helper to generically find such index, appending the module
to the list of modules if it wasn't already (i.e: because it's given via
the "reg" prop).
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
---
v5:
* s/read_fdt_prop_as_reg/fdt_prop_as_reg/
* Move the _u32() prop helper to fdt.c
---
xen/common/domain-builder/fdt.c | 172 +++++++++++++++++++++++++++++++
xen/common/domain-builder/fdt.h | 1 +
xen/include/xen/domain-builder.h | 4 +
3 files changed, 177 insertions(+)
diff --git a/xen/common/domain-builder/fdt.c b/xen/common/domain-builder/fdt.c
index c1ccba39a2..11f0436e85 100644
--- a/xen/common/domain-builder/fdt.c
+++ b/xen/common/domain-builder/fdt.c
@@ -13,6 +13,178 @@
#include "fdt.h"
+static int __init fdt_prop_as_u32(const struct fdt_property *prop,
+ uint32_t *val)
+{
+ if ( !prop || fdt32_to_cpu(prop->len) < sizeof(u32) )
+ return -EINVAL;
+
+ *val = fdt32_to_cpu(*(const fdt32_t *)prop->data);
+ return 0;
+}
+
+/*
+ * Unpacks a "reg" property into its address and size constituents.
+ *
+ * @param prop Pointer to an FDT "reg" property.
+ * @param address_cells Number of 4-octet cells that make up an "address".
+ * @param size_cells Number of 4-octet cells that make up a "size".
+ * @param p_addr[out] Address encoded in the property.
+ * @param p_size[out] Size encoded in the property.
+ * @returns -EINVAL on malformed property, 0 otherwise.
+ */
+static int __init fdt_prop_as_reg(const struct fdt_property *prop,
+ int address_cells, int size_cells,
+ uint64_t *p_addr, uint64_t *p_size)
+{
+ const fdt32_t *cell = (const fdt32_t *)prop->data;
+ uint64_t addr, size;
+
+ if ( fdt32_to_cpu(prop->len) !=
+ (address_cells + size_cells) * sizeof(*cell) )
+ {
+ printk(XENLOG_ERR " cannot read reg %lu+%lu from prop len %u\n",
+ address_cells * sizeof(*cell), size_cells * sizeof(*cell),
+ fdt32_to_cpu(prop->len));
+ return -EINVAL;
+ }
+
+ switch ( address_cells )
+ {
+ case 1:
+ addr = fdt32_to_cpu(*cell);
+ break;
+ case 2:
+ addr = fdt64_to_cpu(*(const fdt64_t *)cell);
+ break;
+ default:
+ printk(XENLOG_ERR " unsupported address_cells=%d\n", address_cells);
+ return -EINVAL;
+ }
+
+ cell += address_cells;
+ switch ( size_cells )
+ {
+ case 1:
+ size = fdt32_to_cpu(*cell);
+ break;
+ case 2:
+ size = fdt64_to_cpu(*(const fdt64_t *)cell);
+ break;
+ default:
+ printk(XENLOG_ERR " unsupported size_cells=%d\n", size_cells);
+ return -EINVAL;
+ }
+
+ *p_addr = addr;
+ *p_size = size;
+
+ return 0;
+}
+
+/*
+ * Locate a multiboot module given its node offset in the FDT.
+ *
+ * The module location may be given via either FDT property:
+ * * reg = <address, size>
+ * * Mutates `bi` to append the module.
+ * * module-index = <idx>
+ * * Leaves `bi` unchanged.
+ *
+ * @param fdt Pointer to the full FDT.
+ * @param node Offset for the module node.
+ * @param address_cells Number of 4-octet cells that make up an "address".
+ * @param size_cells Number of 4-octet cells that make up a "size".
+ * @param bi[inout] Xen's representation of the boot parameters.
+ * @return -EINVAL on malformed nodes, otherwise
+ * index inside `bi->mods`
+ */
+int __init fdt_read_multiboot_module(const void *fdt, int node,
+ int address_cells, int size_cells,
+ struct boot_info *bi)
+{
+ const struct fdt_property *prop;
+ uint64_t addr, size;
+ int ret;
+ uint32_t idx;
+
+ if ( fdt_node_check_compatible(fdt, node, "multiboot,module") )
+ {
+ printk(XENLOG_ERR " bad module. multiboot,module not found");
+ return -ENODATA;
+ }
+
+ /* Location given as a `module-index` property. */
+ if ( (prop = fdt_get_property(fdt, node, "module-index", NULL)) )
+ {
+ if ( fdt_get_property(fdt, node, "reg", NULL) )
+ {
+ printk(XENLOG_ERR " found both reg and module-index for module\n");
+ return -EINVAL;
+ }
+ if ( (ret = fdt_prop_as_u32(prop, &idx)) )
+ {
+ printk(XENLOG_ERR " bad module-index prop\n");
+ return ret;
+ }
+ if ( idx >= MAX_NR_BOOTMODS )
+ {
+ printk(XENLOG_ERR " module-index overflow. %s=%u\n",
+ STR(MAX_NR_BOOTMODS), MAX_NR_BOOTMODS);
+ return -EINVAL;
+ }
+
+ return idx;
+ }
+
+ /* Otherwise location given as a `reg` property. */
+ if ( !(prop = fdt_get_property(fdt, node, "reg", NULL)) )
+ {
+ printk(XENLOG_ERR " no location for multiboot,module\n");
+ return -EINVAL;
+ }
+ if ( fdt_get_property(fdt, node, "module-index", NULL) )
+ {
+ printk(XENLOG_ERR " found both reg and module-index for module\n");
+ return -EINVAL;
+ }
+
+ ret = fdt_prop_as_reg(prop, address_cells, size_cells, &addr, &size);
+ if ( ret < 0 )
+ {
+ printk(XENLOG_ERR " failed reading reg for multiboot,module\n");
+ return -EINVAL;
+ }
+
+ idx = bi->nr_modules;
+ if ( idx > MAX_NR_BOOTMODS )
+ {
+ /*
+ * MAX_NR_BOOTMODS must fit in 31 bits so it's representable in the
+ * positive side of an int; for the return value.
+ */
+ BUILD_BUG_ON(MAX_NR_BOOTMODS > (uint64_t)INT_MAX);
+ printk(XENLOG_ERR " idx=%u exceeds len=%u\n", idx, MAX_NR_BOOTMODS);
+ return -EINVAL;
+ }
+
+ /*
+ * Append new module to the existing list
+ *
+ * Note that bi->nr_modules points to Xen itself, so we must shift it first
+ */
+ bi->nr_modules++;
+ bi->mods[bi->nr_modules] = bi->mods[idx];
+ bi->mods[idx] = (struct boot_module){
+ .start = addr,
+ .size = size,
+ };
+
+ printk(XENLOG_INFO " module[%u]: addr %lx size %lx\n", idx, addr, size);
+
+ return idx;
+}
+
static int __init find_hyperlaunch_node(const void *fdt)
{
int hv_node = fdt_path_offset(fdt, "/chosen/hypervisor");
diff --git a/xen/common/domain-builder/fdt.h b/xen/common/domain-builder/fdt.h
index 826c0f01e5..f48456acd2 100644
--- a/xen/common/domain-builder/fdt.h
+++ b/xen/common/domain-builder/fdt.h
@@ -3,6 +3,7 @@
#define __XEN_DOMAIN_BUILDER_FDT_H__
#include <xen/domain-builder.h>
+#include <xen/libfdt/libfdt-xen.h>
struct boot_info;
diff --git a/xen/include/xen/domain-builder.h b/xen/include/xen/domain-builder.h
index cbb3cbea7c..3ac3a0ab84 100644
--- a/xen/include/xen/domain-builder.h
+++ b/xen/include/xen/domain-builder.h
@@ -28,4 +28,8 @@ static inline enum fdt_kind builder_init(struct boot_info *bi)
}
#endif /* !IS_ENABLED(CONFIG_DOMAIN_BUILDER) */
+int fdt_read_multiboot_module(const void *fdt, int node,
+ int address_cells, int size_cells,
+ struct boot_info *bi)
+
#endif /* __XEN_DOMAIN_BUILDER_H__ */
--
2.43.0
^ permalink raw reply related [flat|nested] 23+ messages in thread* [PATCH v5 05/12] x86/hyperlaunch: locate dom0 kernel with hyperlaunch
2025-04-24 16:10 [PATCH v5 00/12] Hyperlaunch device tree for dom0 Alejandro Vallejo
` (3 preceding siblings ...)
2025-04-24 16:10 ` [PATCH v5 04/12] x86/hyperlaunch: Add helpers to locate multiboot modules Alejandro Vallejo
@ 2025-04-24 16:10 ` Alejandro Vallejo
2025-04-25 22:32 ` Daniel P. Smith
2025-04-24 16:10 ` [PATCH v5 06/12] x86/hyperlaunch: obtain cmdline from device tree Alejandro Vallejo
` (7 subsequent siblings)
12 siblings, 1 reply; 23+ messages in thread
From: Alejandro Vallejo @ 2025-04-24 16:10 UTC (permalink / raw)
To: xen-devel
Cc: Daniel P. Smith, Jan Beulich, Andrew Cooper, Roger Pau Monné,
Anthony PERARD, Michal Orzel, Julien Grall, Stefano Stabellini,
Jason Andryuk, Alejandro Vallejo
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Look for a subnode of type `multiboot,kernel` within a domain node. If
found, locate it using the multiboot module helper to generically ensure
it lives in the module list. If the bootargs property is present and
there was not an MB1 string, then use the command line from the device
tree definition.
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
---
v5:
* Add domain name to the error path on no-kernel.
---
xen/arch/x86/setup.c | 1 +
xen/common/domain-builder/fdt.c | 64 +++++++++++++++++++++++++++++++--
2 files changed, 62 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index bd13d9d196..7e756302ae 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1290,6 +1290,7 @@ void asmlinkage __init noreturn __start_xen(void)
i = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
bi->mods[i].type = BOOTMOD_KERNEL;
bi->domains[0].kernel = &bi->mods[i];
+ bi->nr_domains = 1;
bi->hyperlaunch_enabled = false;
}
diff --git a/xen/common/domain-builder/fdt.c b/xen/common/domain-builder/fdt.c
index 11f0436e85..662c715483 100644
--- a/xen/common/domain-builder/fdt.c
+++ b/xen/common/domain-builder/fdt.c
@@ -99,9 +99,9 @@ static int __init fdt_prop_as_reg(const struct fdt_property *prop,
* @return -EINVAL on malformed nodes, otherwise
* index inside `bi->mods`
*/
-int __init fdt_read_multiboot_module(const void *fdt, int node,
- int address_cells, int size_cells,
- struct boot_info *bi)
+static int __init fdt_read_multiboot_module(const void *fdt, int node,
+ int address_cells, int size_cells,
+ struct boot_info *bi)
{
const struct fdt_property *prop;
uint64_t addr, size;
@@ -185,6 +185,52 @@ int __init fdt_read_multiboot_module(const void *fdt, int node,
return idx;
}
+static int __init process_domain_node(
+ struct boot_info *bi, const void *fdt, int dom_node)
+{
+ int node;
+ struct boot_domain *bd = &bi->domains[bi->nr_domains];
+ const char *name = fdt_get_name(fdt, dom_node, NULL) ?: "unknown";
+ int address_cells = fdt_address_cells(fdt, dom_node);
+ int size_cells = fdt_size_cells(fdt, dom_node);
+
+ fdt_for_each_subnode(node, fdt, dom_node)
+ {
+ if ( !fdt_node_check_compatible(fdt, node, "multiboot,kernel") )
+ {
+ int idx;
+
+ if ( bd->kernel )
+ {
+ printk(XENLOG_WARNING
+ " duplicate kernel for domain %s\n", name);
+ continue;
+ }
+
+ idx = fdt_read_multiboot_module(fdt, node, address_cells,
+ size_cells, bi);
+ if ( idx < 0 )
+ {
+ printk(XENLOG_ERR
+ " failed processing kernel for domain %s\n", name);
+ return idx;
+ }
+
+ printk(XENLOG_INFO " kernel: multiboot-index=%d\n", idx);
+ bi->mods[idx].type = BOOTMOD_KERNEL;
+ bd->kernel = &bi->mods[idx];
+ }
+ }
+
+ if ( !bd->kernel )
+ {
+ printk(XENLOG_ERR "error: no kernel assigned to domain %s\n", name);
+ return -ENODATA;
+ }
+
+ return 0;
+}
+
static int __init find_hyperlaunch_node(const void *fdt)
{
int hv_node = fdt_path_offset(fdt, "/chosen/hypervisor");
@@ -248,8 +294,20 @@ int __init walk_hyperlaunch_fdt(struct boot_info *bi)
fdt_for_each_subnode(node, fdt, hv_node)
{
+ if ( bi->nr_domains >= MAX_NR_BOOTDOMS )
+ {
+ printk(XENLOG_WARNING "warning: only creating first %u domains\n",
+ MAX_NR_BOOTDOMS);
+ break;
+ }
+
if ( !fdt_node_check_compatible(fdt, node, "xen,domain") )
+ {
+ if ( (ret = process_domain_node(bi, fdt, node)) < 0 )
+ break;
+
bi->nr_domains++;
+ }
}
/* Until multi-domain construction is added, throw an error */
--
2.43.0
^ permalink raw reply related [flat|nested] 23+ messages in thread* Re: [PATCH v5 05/12] x86/hyperlaunch: locate dom0 kernel with hyperlaunch
2025-04-24 16:10 ` [PATCH v5 05/12] x86/hyperlaunch: locate dom0 kernel with hyperlaunch Alejandro Vallejo
@ 2025-04-25 22:32 ` Daniel P. Smith
2025-04-28 11:05 ` Alejandro Vallejo
0 siblings, 1 reply; 23+ messages in thread
From: Daniel P. Smith @ 2025-04-25 22:32 UTC (permalink / raw)
To: Alejandro Vallejo, xen-devel
Cc: Jan Beulich, Andrew Cooper, Roger Pau Monné, Anthony PERARD,
Michal Orzel, Julien Grall, Stefano Stabellini, Jason Andryuk
On 4/24/25 12:10, Alejandro Vallejo wrote:
> From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
>
> Look for a subnode of type `multiboot,kernel` within a domain node. If
> found, locate it using the multiboot module helper to generically ensure
> it lives in the module list. If the bootargs property is present and
> there was not an MB1 string, then use the command line from the device
> tree definition.
>
> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
> Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
> ---
> v5:
> * Add domain name to the error path on no-kernel.
> ---
> xen/arch/x86/setup.c | 1 +
> xen/common/domain-builder/fdt.c | 64 +++++++++++++++++++++++++++++++--
> 2 files changed, 62 insertions(+), 3 deletions(-)
>
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index bd13d9d196..7e756302ae 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1290,6 +1290,7 @@ void asmlinkage __init noreturn __start_xen(void)
> i = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
> bi->mods[i].type = BOOTMOD_KERNEL;
> bi->domains[0].kernel = &bi->mods[i];
> + bi->nr_domains = 1;
> bi->hyperlaunch_enabled = false;
> }
>
> diff --git a/xen/common/domain-builder/fdt.c b/xen/common/domain-builder/fdt.c
> index 11f0436e85..662c715483 100644
> --- a/xen/common/domain-builder/fdt.c
> +++ b/xen/common/domain-builder/fdt.c
> @@ -99,9 +99,9 @@ static int __init fdt_prop_as_reg(const struct fdt_property *prop,
> * @return -EINVAL on malformed nodes, otherwise
> * index inside `bi->mods`
> */
> -int __init fdt_read_multiboot_module(const void *fdt, int node,
> - int address_cells, int size_cells,
> - struct boot_info *bi)
> +static int __init fdt_read_multiboot_module(const void *fdt, int node,
> + int address_cells, int size_cells,
> + struct boot_info *bi)
Shouldn't this belong to when the function was introduced? Though
looking there, you push it out into the header? Guess the real question
is it static or not?
> {
> const struct fdt_property *prop;
> uint64_t addr, size;
> @@ -185,6 +185,52 @@ int __init fdt_read_multiboot_module(const void *fdt, int node,
> return idx;
> }
>
> +static int __init process_domain_node(
> + struct boot_info *bi, const void *fdt, int dom_node)
> +{
> + int node;
> + struct boot_domain *bd = &bi->domains[bi->nr_domains];
> + const char *name = fdt_get_name(fdt, dom_node, NULL) ?: "unknown";
> + int address_cells = fdt_address_cells(fdt, dom_node);
> + int size_cells = fdt_size_cells(fdt, dom_node);
> +
> + fdt_for_each_subnode(node, fdt, dom_node)
> + {
> + if ( !fdt_node_check_compatible(fdt, node, "multiboot,kernel") )
> + {
> + int idx;
> +
> + if ( bd->kernel )
> + {
> + printk(XENLOG_WARNING
> + " duplicate kernel for domain %s\n", name);
> + continue;
> + }
> +
> + idx = fdt_read_multiboot_module(fdt, node, address_cells,
> + size_cells, bi);
> + if ( idx < 0 )
> + {
> + printk(XENLOG_ERR
> + " failed processing kernel for domain %s\n", name);
> + return idx;
> + }
> +
> + printk(XENLOG_INFO " kernel: multiboot-index=%d\n", idx);
> + bi->mods[idx].type = BOOTMOD_KERNEL;
> + bd->kernel = &bi->mods[idx];
> + }
> + }
> +
> + if ( !bd->kernel )
> + {
> + printk(XENLOG_ERR "error: no kernel assigned to domain %s\n", name);
> + return -ENODATA;
> + }
> +
> + return 0;
> +}
> +
> static int __init find_hyperlaunch_node(const void *fdt)
> {
> int hv_node = fdt_path_offset(fdt, "/chosen/hypervisor");
> @@ -248,8 +294,20 @@ int __init walk_hyperlaunch_fdt(struct boot_info *bi)
>
> fdt_for_each_subnode(node, fdt, hv_node)
> {
> + if ( bi->nr_domains >= MAX_NR_BOOTDOMS )
> + {
> + printk(XENLOG_WARNING "warning: only creating first %u domains\n",
> + MAX_NR_BOOTDOMS);
> + break;
> + }
> +
> if ( !fdt_node_check_compatible(fdt, node, "xen,domain") )
> + {
> + if ( (ret = process_domain_node(bi, fdt, node)) < 0 )
> + break;
> +
> bi->nr_domains++;
> + }
> }
>
> /* Until multi-domain construction is added, throw an error */
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [PATCH v5 05/12] x86/hyperlaunch: locate dom0 kernel with hyperlaunch
2025-04-25 22:32 ` Daniel P. Smith
@ 2025-04-28 11:05 ` Alejandro Vallejo
0 siblings, 0 replies; 23+ messages in thread
From: Alejandro Vallejo @ 2025-04-28 11:05 UTC (permalink / raw)
To: Daniel P. Smith, xen-devel
Cc: Jan Beulich, Andrew Cooper, Roger Pau Monné, Anthony PERARD,
Michal Orzel, Julien Grall, Stefano Stabellini, Jason Andryuk
On Fri Apr 25, 2025 at 11:32 PM BST, Daniel P. Smith wrote:
> On 4/24/25 12:10, Alejandro Vallejo wrote:
>> From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
>>
>> Look for a subnode of type `multiboot,kernel` within a domain node. If
>> found, locate it using the multiboot module helper to generically ensure
>> it lives in the module list. If the bootargs property is present and
>> there was not an MB1 string, then use the command line from the device
>> tree definition.
>>
>> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
>> Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
>> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
>> ---
>> v5:
>> * Add domain name to the error path on no-kernel.
>> ---
>> xen/arch/x86/setup.c | 1 +
>> xen/common/domain-builder/fdt.c | 64 +++++++++++++++++++++++++++++++--
>> 2 files changed, 62 insertions(+), 3 deletions(-)
>>
>> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
>> index bd13d9d196..7e756302ae 100644
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -1290,6 +1290,7 @@ void asmlinkage __init noreturn __start_xen(void)
>> i = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
>> bi->mods[i].type = BOOTMOD_KERNEL;
>> bi->domains[0].kernel = &bi->mods[i];
>> + bi->nr_domains = 1;
>> bi->hyperlaunch_enabled = false;
>> }
>>
>> diff --git a/xen/common/domain-builder/fdt.c b/xen/common/domain-builder/fdt.c
>> index 11f0436e85..662c715483 100644
>> --- a/xen/common/domain-builder/fdt.c
>> +++ b/xen/common/domain-builder/fdt.c
>> @@ -99,9 +99,9 @@ static int __init fdt_prop_as_reg(const struct fdt_property *prop,
>> * @return -EINVAL on malformed nodes, otherwise
>> * index inside `bi->mods`
>> */
>> -int __init fdt_read_multiboot_module(const void *fdt, int node,
>> - int address_cells, int size_cells,
>> - struct boot_info *bi)
>> +static int __init fdt_read_multiboot_module(const void *fdt, int node,
>> + int address_cells, int size_cells,
>> + struct boot_info *bi)
>
> Shouldn't this belong to when the function was introduced? Though
> looking there, you push it out into the header? Guess the real question
> is it static or not?
It's to ensure MISRA compliance on the previous commit. See:
https://lore.kernel.org/xen-devel/173f7129e82958a9737627129ac3c5be@bugseng.com/
Cheers,
Alejandro
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH v5 06/12] x86/hyperlaunch: obtain cmdline from device tree
2025-04-24 16:10 [PATCH v5 00/12] Hyperlaunch device tree for dom0 Alejandro Vallejo
` (4 preceding siblings ...)
2025-04-24 16:10 ` [PATCH v5 05/12] x86/hyperlaunch: locate dom0 kernel with hyperlaunch Alejandro Vallejo
@ 2025-04-24 16:10 ` Alejandro Vallejo
2025-04-24 16:10 ` [PATCH v5 07/12] x86/hyperlaunch: locate dom0 initrd with hyperlaunch Alejandro Vallejo
` (6 subsequent siblings)
12 siblings, 0 replies; 23+ messages in thread
From: Alejandro Vallejo @ 2025-04-24 16:10 UTC (permalink / raw)
To: xen-devel
Cc: Daniel P. Smith, Jan Beulich, Andrew Cooper, Roger Pau Monné,
Anthony PERARD, Michal Orzel, Julien Grall, Stefano Stabellini,
Bertrand Marquis, Jason Andryuk, Alejandro Vallejo
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Add support to read the command line from the hyperlaunch device tree.
The device tree command line is located in the "bootargs" property of the
"multiboot,kernel" node.
A boot loader command line, e.g. a grub module string field, takes
precendence over the device tree one since it is easier to modify.
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
---
v5:
* Fixed typo on commit message
* Added BUG_ON() statements on fdt cmdline parsers in setup.c so they
are skipped on !CONFIG_DOMAIN_BUILDER
* Add cmdline handling comment to the domain_cmdline_size()
---
xen/arch/x86/include/asm/bootinfo.h | 6 ++++--
xen/arch/x86/setup.c | 22 ++++++++++++++++++++--
xen/common/domain-builder/core.c | 26 ++++++++++++++++++++++++++
xen/common/domain-builder/fdt.c | 6 ++++++
xen/common/domain-builder/fdt.h | 24 ++++++++++++++++++++++++
xen/include/xen/domain-builder.h | 8 +++++---
xen/include/xen/libfdt/libfdt-xen.h | 23 +++++++++++++++++++++++
7 files changed, 108 insertions(+), 7 deletions(-)
diff --git a/xen/arch/x86/include/asm/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h
index 1e3d582e45..5b2c93b1ef 100644
--- a/xen/arch/x86/include/asm/bootinfo.h
+++ b/xen/arch/x86/include/asm/bootinfo.h
@@ -35,11 +35,13 @@ struct boot_module {
/*
* Module State Flags:
- * relocated: indicates module has been relocated in memory.
- * released: indicates module's pages have been freed.
+ * relocated: indicates module has been relocated in memory.
+ * released: indicates module's pages have been freed.
+ * fdt_cmdline: indicates module's cmdline is in the FDT.
*/
bool relocated:1;
bool released:1;
+ bool fdt_cmdline:1;
/*
* A boot module may need decompressing by Xen. Headroom is an estimate of
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 7e756302ae..325ba8cc8a 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -984,7 +984,19 @@ static size_t __init domain_cmdline_size(const struct boot_info *bi,
{
size_t s = bi->kextra ? strlen(bi->kextra) : 0;
- s += bd->kernel->cmdline_pa ? strlen(__va(bd->kernel->cmdline_pa)) : 0;
+
+ /*
+ * Bootloader cmdline takes precedence and replaces the DT provided one.
+ *
+ * In that case, fdt_cmdline is not be populated at all.
+ */
+ if ( bd->kernel->fdt_cmdline )
+ {
+ BUG_ON(!IS_ENABLED(CONFIG_DOMAIN_BUILDER));
+ s += builder_get_cmdline_size(bi, bd->kernel->cmdline_pa);
+ }
+ else if ( bd->kernel->cmdline_pa )
+ s += strlen(__va(bd->kernel->cmdline_pa));
if ( s == 0 )
return s;
@@ -1048,7 +1060,13 @@ static struct domain *__init create_dom0(struct boot_info *bi)
if ( !(cmdline = xzalloc_array(char, cmdline_size)) )
panic("Error allocating cmdline buffer for %pd\n", d);
- if ( bd->kernel->cmdline_pa )
+ if ( bd->kernel->fdt_cmdline )
+ {
+ BUG_ON(!IS_ENABLED(CONFIG_DOMAIN_BUILDER));
+ builder_get_cmdline(
+ bi, bd->kernel->cmdline_pa, cmdline, cmdline_size);
+ }
+ else if ( bd->kernel->cmdline_pa )
strlcpy(cmdline,
cmdline_cook(__va(bd->kernel->cmdline_pa), bi->loader),
cmdline_size);
diff --git a/xen/common/domain-builder/core.c b/xen/common/domain-builder/core.c
index 0955558977..0b7a21a4b8 100644
--- a/xen/common/domain-builder/core.c
+++ b/xen/common/domain-builder/core.c
@@ -10,9 +10,35 @@
#include <xen/lib.h>
#include <asm/bootinfo.h>
+#include <asm/setup.h>
#include "fdt.h"
+size_t __init builder_get_cmdline_size(const struct boot_info *bi, int offset)
+{
+ const void *fdt;
+ int size;
+
+ fdt = bootstrap_map_bm(&bi->mods[HYPERLAUNCH_MODULE_IDX]);
+ size = fdt_cmdline_prop_size(fdt, offset);
+ bootstrap_unmap();
+
+ return max(0, size);
+}
+
+int __init builder_get_cmdline(const struct boot_info *bi,
+ int offset, char *cmdline, size_t size)
+{
+ const void *fdt;
+ int ret;
+
+ fdt = bootstrap_map_bm(&bi->mods[HYPERLAUNCH_MODULE_IDX]);
+ ret = fdt_cmdline_prop_copy(fdt, offset, cmdline, size);
+ bootstrap_unmap();
+
+ return ret;
+}
+
enum fdt_kind __init builder_init(struct boot_info *bi)
{
enum fdt_kind kind;
diff --git a/xen/common/domain-builder/fdt.c b/xen/common/domain-builder/fdt.c
index 662c715483..fa92dc55b2 100644
--- a/xen/common/domain-builder/fdt.c
+++ b/xen/common/domain-builder/fdt.c
@@ -219,6 +219,12 @@ static int __init process_domain_node(
printk(XENLOG_INFO " kernel: multiboot-index=%d\n", idx);
bi->mods[idx].type = BOOTMOD_KERNEL;
bd->kernel = &bi->mods[idx];
+
+ /* If bootloader didn't set cmdline, see if FDT provides one. */
+ if ( bd->kernel->cmdline_pa &&
+ !((char *)__va(bd->kernel->cmdline_pa))[0] )
+ bd->kernel->fdt_cmdline = fdt_get_prop_offset(
+ fdt, node, "bootargs", &bd->kernel->cmdline_pa);
}
}
diff --git a/xen/common/domain-builder/fdt.h b/xen/common/domain-builder/fdt.h
index f48456acd2..e1243cbf26 100644
--- a/xen/common/domain-builder/fdt.h
+++ b/xen/common/domain-builder/fdt.h
@@ -10,6 +10,30 @@ struct boot_info;
/* hyperlaunch fdt is required to be module 0 */
#define HYPERLAUNCH_MODULE_IDX 0
+static inline int __init fdt_cmdline_prop_size(const void *fdt, int offset)
+{
+ int ret;
+
+ fdt_get_property_by_offset(fdt, offset, &ret);
+
+ return ret;
+}
+
+static inline int __init fdt_cmdline_prop_copy(
+ const void *fdt, int offset, char *cmdline, size_t size)
+{
+ int ret;
+ const struct fdt_property *prop =
+ fdt_get_property_by_offset(fdt, offset, &ret);
+
+ if ( ret < 0 )
+ return ret;
+
+ ASSERT(size > ret);
+
+ return strlcpy(cmdline, prop->data, ret);
+}
+
enum fdt_kind detect_fdt_kind(const struct boot_info *bi);
int walk_hyperlaunch_fdt(struct boot_info *bi);
diff --git a/xen/include/xen/domain-builder.h b/xen/include/xen/domain-builder.h
index 3ac3a0ab84..350e2eb2af 100644
--- a/xen/include/xen/domain-builder.h
+++ b/xen/include/xen/domain-builder.h
@@ -2,6 +2,8 @@
#ifndef __XEN_DOMAIN_BUILDER_H__
#define __XEN_DOMAIN_BUILDER_H__
+#include <xen/types.h>
+
struct boot_info;
/* Return status of builder_init(). Shows which boot mechanism was detected */
@@ -28,8 +30,8 @@ static inline enum fdt_kind builder_init(struct boot_info *bi)
}
#endif /* !IS_ENABLED(CONFIG_DOMAIN_BUILDER) */
-int fdt_read_multiboot_module(const void *fdt, int node,
- int address_cells, int size_cells,
- struct boot_info *bi)
+size_t builder_get_cmdline_size(const struct boot_info *bi, int offset);
+int builder_get_cmdline(const struct boot_info *bi, int offset,
+ char *cmdline, size_t size);
#endif /* __XEN_DOMAIN_BUILDER_H__ */
diff --git a/xen/include/xen/libfdt/libfdt-xen.h b/xen/include/xen/libfdt/libfdt-xen.h
index a5340bc9f4..9c20a26a35 100644
--- a/xen/include/xen/libfdt/libfdt-xen.h
+++ b/xen/include/xen/libfdt/libfdt-xen.h
@@ -13,6 +13,29 @@
#include <xen/libfdt/libfdt.h>
+static inline bool __init fdt_get_prop_offset(
+ const void *fdt, int node, const char *pname, unsigned long *poffset)
+{
+ int ret, offset;
+ const char *name;
+
+ fdt_for_each_property_offset(offset, fdt, node)
+ {
+ fdt_getprop_by_offset(fdt, offset, &name, &ret);
+
+ if ( ret < 0 )
+ continue;
+
+ if ( !strcmp(name, pname) )
+ {
+ *poffset = offset;
+ return true;
+ }
+ }
+
+ return false;
+}
+
static inline int fdt_get_mem_rsv_paddr(const void *fdt, int n,
paddr_t *address,
paddr_t *size)
--
2.43.0
^ permalink raw reply related [flat|nested] 23+ messages in thread* [PATCH v5 07/12] x86/hyperlaunch: locate dom0 initrd with hyperlaunch
2025-04-24 16:10 [PATCH v5 00/12] Hyperlaunch device tree for dom0 Alejandro Vallejo
` (5 preceding siblings ...)
2025-04-24 16:10 ` [PATCH v5 06/12] x86/hyperlaunch: obtain cmdline from device tree Alejandro Vallejo
@ 2025-04-24 16:10 ` Alejandro Vallejo
2025-04-24 16:10 ` [PATCH v5 08/12] x86/hyperlaunch: add domain id parsing to domain config Alejandro Vallejo
` (5 subsequent siblings)
12 siblings, 0 replies; 23+ messages in thread
From: Alejandro Vallejo @ 2025-04-24 16:10 UTC (permalink / raw)
To: xen-devel
Cc: Daniel P. Smith, Jan Beulich, Andrew Cooper, Roger Pau Monné,
Anthony PERARD, Michal Orzel, Julien Grall, Stefano Stabellini,
Jason Andryuk, Alejandro Vallejo
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Look for a subnode of type `multiboot,ramdisk` within a domain node and
parse via the fdt_read_multiboot_module() helper. After a successful
helper call, the module index is returned and the module is guaranteed
to be in the module list.
Fix unused typo in adjacent comment.
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
---
v5:
* Propagate errors from fdt_read_multiboot_module()
---
xen/arch/x86/setup.c | 4 ++--
xen/common/domain-builder/fdt.c | 24 ++++++++++++++++++++++++
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 325ba8cc8a..661b80138a 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -2171,11 +2171,11 @@ void asmlinkage __init noreturn __start_xen(void)
* At this point all capabilities that consume boot modules should have
* claimed their boot modules. Find the first unclaimed boot module and
* claim it as the initrd ramdisk. Do a second search to see if there are
- * any remaining unclaimed boot modules, and report them as unusued initrd
+ * any remaining unclaimed boot modules, and report them as unused initrd
* candidates.
*/
initrdidx = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
- if ( initrdidx < MAX_NR_BOOTMODS )
+ if ( !bi->hyperlaunch_enabled && initrdidx < MAX_NR_BOOTMODS )
{
bi->mods[initrdidx].type = BOOTMOD_RAMDISK;
bi->domains[0].module = &bi->mods[initrdidx];
diff --git a/xen/common/domain-builder/fdt.c b/xen/common/domain-builder/fdt.c
index fa92dc55b2..144fcc75b5 100644
--- a/xen/common/domain-builder/fdt.c
+++ b/xen/common/domain-builder/fdt.c
@@ -226,6 +226,30 @@ static int __init process_domain_node(
bd->kernel->fdt_cmdline = fdt_get_prop_offset(
fdt, node, "bootargs", &bd->kernel->cmdline_pa);
}
+ else if ( !fdt_node_check_compatible(fdt, node, "multiboot,ramdisk") )
+ {
+ int idx;
+
+ if ( bd->module )
+ {
+ printk(XENLOG_WARNING
+ "Duplicate module for domain %s\n", name);
+ continue;
+ }
+
+ idx = fdt_read_multiboot_module(fdt, node, address_cells,
+ size_cells, bi);
+ if ( idx < 0 )
+ {
+ printk(XENLOG_ERR " failed processing module for domain %s\n",
+ name);
+ return idx;
+ }
+
+ printk(XENLOG_INFO " module: multiboot-index=%d\n", idx);
+ bi->mods[idx].type = BOOTMOD_RAMDISK;
+ bd->module = &bi->mods[idx];
+ }
}
if ( !bd->kernel )
--
2.43.0
^ permalink raw reply related [flat|nested] 23+ messages in thread* [PATCH v5 08/12] x86/hyperlaunch: add domain id parsing to domain config
2025-04-24 16:10 [PATCH v5 00/12] Hyperlaunch device tree for dom0 Alejandro Vallejo
` (6 preceding siblings ...)
2025-04-24 16:10 ` [PATCH v5 07/12] x86/hyperlaunch: locate dom0 initrd with hyperlaunch Alejandro Vallejo
@ 2025-04-24 16:10 ` Alejandro Vallejo
2025-04-24 17:41 ` Jason Andryuk
2025-04-24 16:10 ` [PATCH v5 09/12] x86/hyperlaunch: specify dom0 mode with device tree Alejandro Vallejo
` (4 subsequent siblings)
12 siblings, 1 reply; 23+ messages in thread
From: Alejandro Vallejo @ 2025-04-24 16:10 UTC (permalink / raw)
To: xen-devel
Cc: Daniel P. Smith, Jan Beulich, Andrew Cooper, Roger Pau Monné,
Anthony PERARD, Michal Orzel, Julien Grall, Stefano Stabellini,
Alejandro Vallejo
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Introduce the ability to specify the desired domain id for the domain
definition. The domain id will be populated in the domid property of the
domain node in the device tree configuration.
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
---
v5:
* Added missing domid to printk (also rewrote it).
---
xen/arch/x86/setup.c | 5 ++--
xen/common/domain-builder/fdt.c | 52 ++++++++++++++++++++++++++++++++-
2 files changed, 54 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 661b80138a..ece77079d8 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1042,8 +1042,9 @@ static struct domain *__init create_dom0(struct boot_info *bi)
if ( iommu_enabled )
dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu;
- /* Create initial domain. Not d0 for pvshim. */
- bd->domid = get_initial_domain_id();
+ if ( bd->domid == DOMID_INVALID )
+ /* Create initial domain. Not d0 for pvshim. */
+ bd->domid = get_initial_domain_id();
d = domain_create(bd->domid, &dom0_cfg,
pv_shim ? 0 : CDF_privileged | CDF_hardware);
if ( IS_ERR(d) )
diff --git a/xen/common/domain-builder/fdt.c b/xen/common/domain-builder/fdt.c
index 144fcc75b5..5a5b3c8806 100644
--- a/xen/common/domain-builder/fdt.c
+++ b/xen/common/domain-builder/fdt.c
@@ -2,6 +2,7 @@
/*
* Copyright (C) 2024, Apertus Solutions, LLC
*/
+#include <xen/domain.h>
#include <xen/err.h>
#include <xen/init.h>
#include <xen/lib.h>
@@ -188,12 +189,54 @@ static int __init fdt_read_multiboot_module(const void *fdt, int node,
static int __init process_domain_node(
struct boot_info *bi, const void *fdt, int dom_node)
{
- int node;
+ int node, property;
struct boot_domain *bd = &bi->domains[bi->nr_domains];
const char *name = fdt_get_name(fdt, dom_node, NULL) ?: "unknown";
int address_cells = fdt_address_cells(fdt, dom_node);
int size_cells = fdt_size_cells(fdt, dom_node);
+ fdt_for_each_property_offset(property, fdt, dom_node)
+ {
+ const struct fdt_property *prop;
+ const char *prop_name;
+ int name_len, rc;
+
+ prop = fdt_get_property_by_offset(fdt, property, NULL);
+ if ( !prop )
+ continue; /* silently skip */
+
+ prop_name = fdt_get_string(fdt, fdt32_to_cpu(prop->nameoff), &name_len);
+
+ if ( !strncmp(prop_name, "domid", name_len) )
+ {
+ uint32_t val = DOMID_INVALID;
+
+ if ( (rc = fdt_prop_as_u32(prop, &val)) )
+ {
+ printk(XENLOG_ERR
+ " failed processing domain id for domain %s\n", name);
+ return rc;
+ }
+ if ( val >= DOMID_FIRST_RESERVED )
+ {
+ printk(XENLOG_ERR " invalid domain id for domain %s\n", name);
+ return -EINVAL;
+ }
+
+ for ( unsigned int i = 0; i < bi->nr_domains; i++ )
+ {
+ if ( bi->domains[i].domid == val )
+ {
+ printk(XENLOG_ERR " duplicate id for domain %s\n", name);
+ return -EINVAL;
+ }
+ }
+
+ bd->domid = val;
+ printk(XENLOG_INFO " domid: %d\n", bd->domid);
+ }
+ }
+
fdt_for_each_subnode(node, fdt, dom_node)
{
if ( !fdt_node_check_compatible(fdt, node, "multiboot,kernel") )
@@ -258,6 +301,13 @@ static int __init process_domain_node(
return -ENODATA;
}
+ if ( bd->domid == DOMID_INVALID )
+ bd->domid = get_initial_domain_id();
+ else if ( bd->domid != get_initial_domain_id() )
+ printk(XENLOG_WARNING
+ "warning: unsupported boot. d%d is not the initial domain.\n",
+ bd->domid);
+
return 0;
}
--
2.43.0
^ permalink raw reply related [flat|nested] 23+ messages in thread* Re: [PATCH v5 08/12] x86/hyperlaunch: add domain id parsing to domain config
2025-04-24 16:10 ` [PATCH v5 08/12] x86/hyperlaunch: add domain id parsing to domain config Alejandro Vallejo
@ 2025-04-24 17:41 ` Jason Andryuk
2025-04-25 12:43 ` Alejandro Vallejo
0 siblings, 1 reply; 23+ messages in thread
From: Jason Andryuk @ 2025-04-24 17:41 UTC (permalink / raw)
To: Alejandro Vallejo, xen-devel
Cc: Daniel P. Smith, Jan Beulich, Andrew Cooper, Roger Pau Monné,
Anthony PERARD, Michal Orzel, Julien Grall, Stefano Stabellini
On 2025-04-24 12:10, Alejandro Vallejo wrote:
> From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
>
> Introduce the ability to specify the desired domain id for the domain
> definition. The domain id will be populated in the domid property of the
> domain node in the device tree configuration.
>
> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
> ---
> diff --git a/xen/common/domain-builder/fdt.c b/xen/common/domain-builder/fdt.c
> index 144fcc75b5..5a5b3c8806 100644
> --- a/xen/common/domain-builder/fdt.c
> +++ b/xen/common/domain-builder/fdt.c
> @@ -188,12 +189,54 @@ static int __init fdt_read_multiboot_module(const void *fdt, int node,
> static int __init process_domain_node(
> struct boot_info *bi, const void *fdt, int dom_node)
> {
> - int node;
> + int node, property;
> struct boot_domain *bd = &bi->domains[bi->nr_domains];
> const char *name = fdt_get_name(fdt, dom_node, NULL) ?: "unknown";
> int address_cells = fdt_address_cells(fdt, dom_node);
> int size_cells = fdt_size_cells(fdt, dom_node);
>
> + fdt_for_each_property_offset(property, fdt, dom_node)
> + {
> + const struct fdt_property *prop;
> + const char *prop_name;
> + int name_len, rc;
> +
> + prop = fdt_get_property_by_offset(fdt, property, NULL);
> + if ( !prop )
> + continue; /* silently skip */
> +
> + prop_name = fdt_get_string(fdt, fdt32_to_cpu(prop->nameoff), &name_len);
> +
Stray blank line.
> + if ( !strncmp(prop_name, "domid", name_len) )
> + {
> + uint32_t val = DOMID_INVALID;
> +
> + if ( (rc = fdt_prop_as_u32(prop, &val)) )
> + {
> + printk(XENLOG_ERR
> + " failed processing domain id for domain %s\n", name);
> + return rc;
> + }
Maybe add a blank line here?
> + if ( val >= DOMID_FIRST_RESERVED )
> + {
> + printk(XENLOG_ERR " invalid domain id for domain %s\n", name);
> + return -EINVAL;
> + }
> +
> @@ -258,6 +301,13 @@ static int __init process_domain_node(
> return -ENODATA;
> }
>
> + if ( bd->domid == DOMID_INVALID )
> + bd->domid = get_initial_domain_id();
> + else if ( bd->domid != get_initial_domain_id() )
> + printk(XENLOG_WARNING
> + "warning: unsupported boot. d%d is not the initial domain.\n",
Maybe:
"warning: d%u is not the expected initial domid (%u)\n" ?
It's a strange message. The domid property is added, but it's not
expected to actually be used?
With the newlines addressed (and optionally the message change):
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Thanks,
Jason
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [PATCH v5 08/12] x86/hyperlaunch: add domain id parsing to domain config
2025-04-24 17:41 ` Jason Andryuk
@ 2025-04-25 12:43 ` Alejandro Vallejo
0 siblings, 0 replies; 23+ messages in thread
From: Alejandro Vallejo @ 2025-04-25 12:43 UTC (permalink / raw)
To: Jason Andryuk, xen-devel
Cc: Daniel P. Smith, Jan Beulich, Andrew Cooper, Roger Pau Monné,
Anthony PERARD, Michal Orzel, Julien Grall, Stefano Stabellini
On Thu Apr 24, 2025 at 6:41 PM BST, Jason Andryuk wrote:
> On 2025-04-24 12:10, Alejandro Vallejo wrote:
>> From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
>>
>> Introduce the ability to specify the desired domain id for the domain
>> definition. The domain id will be populated in the domid property of the
>> domain node in the device tree configuration.
>>
>> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
>> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
>> ---
>
>> diff --git a/xen/common/domain-builder/fdt.c b/xen/common/domain-builder/fdt.c
>> index 144fcc75b5..5a5b3c8806 100644
>> --- a/xen/common/domain-builder/fdt.c
>> +++ b/xen/common/domain-builder/fdt.c
>
>> @@ -188,12 +189,54 @@ static int __init fdt_read_multiboot_module(const void *fdt, int node,
>> static int __init process_domain_node(
>> struct boot_info *bi, const void *fdt, int dom_node)
>> {
>> - int node;
>> + int node, property;
>> struct boot_domain *bd = &bi->domains[bi->nr_domains];
>> const char *name = fdt_get_name(fdt, dom_node, NULL) ?: "unknown";
>> int address_cells = fdt_address_cells(fdt, dom_node);
>> int size_cells = fdt_size_cells(fdt, dom_node);
>>
>> + fdt_for_each_property_offset(property, fdt, dom_node)
>> + {
>> + const struct fdt_property *prop;
>> + const char *prop_name;
>> + int name_len, rc;
>> +
>> + prop = fdt_get_property_by_offset(fdt, property, NULL);
>> + if ( !prop )
>> + continue; /* silently skip */
>> +
>> + prop_name = fdt_get_string(fdt, fdt32_to_cpu(prop->nameoff), &name_len);
>> +
>
> Stray blank line.
>
>> + if ( !strncmp(prop_name, "domid", name_len) )
>> + {
>> + uint32_t val = DOMID_INVALID;
>> +
>> + if ( (rc = fdt_prop_as_u32(prop, &val)) )
>> + {
>> + printk(XENLOG_ERR
>> + " failed processing domain id for domain %s\n", name);
>> + return rc;
>> + }
>
> Maybe add a blank line here?
>
>> + if ( val >= DOMID_FIRST_RESERVED )
>> + {
>> + printk(XENLOG_ERR " invalid domain id for domain %s\n", name);
>> + return -EINVAL;
>> + }
>> +
>
>> @@ -258,6 +301,13 @@ static int __init process_domain_node(
>> return -ENODATA;
>> }
>>
>> + if ( bd->domid == DOMID_INVALID )
>> + bd->domid = get_initial_domain_id();
>> + else if ( bd->domid != get_initial_domain_id() )
>> + printk(XENLOG_WARNING
>> + "warning: unsupported boot. d%d is not the initial domain.\n",
>
> Maybe:
> "warning: d%u is not the expected initial domid (%u)\n" ?
>
> It's a strange message. The domid property is added, but it's not
> expected to actually be used?
It's just a transient message until multidomain boot is added in a later
series. It's merely informative that you're booting something you
probably didn't mean to. Or didn't mean to on this hypervisor.
>
> With the newlines addressed (and optionally the message change):
I'm happy to make those adjustments.
>
> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Thanks
>
> Thanks,
> Jason
Cheers,
Alejandro
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH v5 09/12] x86/hyperlaunch: specify dom0 mode with device tree
2025-04-24 16:10 [PATCH v5 00/12] Hyperlaunch device tree for dom0 Alejandro Vallejo
` (7 preceding siblings ...)
2025-04-24 16:10 ` [PATCH v5 08/12] x86/hyperlaunch: add domain id parsing to domain config Alejandro Vallejo
@ 2025-04-24 16:10 ` Alejandro Vallejo
2025-04-24 16:10 ` [PATCH v5 10/12] x86/hyperlaunch: add memory parsing to domain config Alejandro Vallejo
` (3 subsequent siblings)
12 siblings, 0 replies; 23+ messages in thread
From: Alejandro Vallejo @ 2025-04-24 16:10 UTC (permalink / raw)
To: xen-devel
Cc: Daniel P. Smith, Jan Beulich, Andrew Cooper, Roger Pau Monné,
Anthony PERARD, Michal Orzel, Julien Grall, Stefano Stabellini,
Jason Andryuk, Alejandro Vallejo, Denis Mukhin
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Enable selecting the mode in which the domain will be built and ran. This
includes:
- whether it will be either a 32/64 bit domain
- if it will be run as a PV or HVM domain
- and if it will require a device model (not applicable for dom0)
In the device tree, this will be represented as a bit map that will be carried
through into struct boot_domain.
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
---
xen/arch/x86/include/asm/boot-domain.h | 5 +++++
xen/arch/x86/setup.c | 3 ++-
xen/common/domain-builder/fdt.c | 21 +++++++++++++++++++++
3 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/include/asm/boot-domain.h b/xen/arch/x86/include/asm/boot-domain.h
index d7c6042e25..e316d4bcde 100644
--- a/xen/arch/x86/include/asm/boot-domain.h
+++ b/xen/arch/x86/include/asm/boot-domain.h
@@ -13,6 +13,11 @@
struct boot_domain {
domid_t domid;
+ /* On | Off */
+#define BUILD_MODE_PARAVIRT (1 << 0) /* PV | PVH/HVM */
+#define BUILD_MODE_ENABLE_DM (1 << 1) /* HVM | PVH */
+ uint32_t mode;
+
struct boot_module *kernel;
struct boot_module *module;
const char *cmdline;
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index ece77079d8..d3a4f89a6a 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1029,7 +1029,8 @@ static struct domain *__init create_dom0(struct boot_info *bi)
struct boot_domain *bd = &bi->domains[0];
struct domain *d;
- if ( opt_dom0_pvh )
+ if ( opt_dom0_pvh ||
+ (bi->hyperlaunch_enabled && !(bd->mode & BUILD_MODE_PARAVIRT)) )
{
dom0_cfg.flags |= (XEN_DOMCTL_CDF_hvm |
((hvm_hap_supported() && !opt_dom0_shadow) ?
diff --git a/xen/common/domain-builder/fdt.c b/xen/common/domain-builder/fdt.c
index 5a5b3c8806..75f68de448 100644
--- a/xen/common/domain-builder/fdt.c
+++ b/xen/common/domain-builder/fdt.c
@@ -235,6 +235,27 @@ static int __init process_domain_node(
bd->domid = val;
printk(XENLOG_INFO " domid: %d\n", bd->domid);
}
+ else if ( !strncmp(prop_name, "mode", name_len) )
+ {
+ if ( (rc = fdt_prop_as_u32(prop, &bd->mode)) )
+ {
+ printk(XENLOG_ERR
+ " failed processing mode for domain %s\n", name);
+ return rc;
+ }
+
+ if ( (bd->mode & BUILD_MODE_PARAVIRT) &&
+ (bd->mode & BUILD_MODE_ENABLE_DM) )
+ {
+ printk(XENLOG_ERR " mode: invalid (pv+hvm)\n");
+ return -EINVAL;
+ }
+
+ printk(XENLOG_INFO " mode: %s\n",
+ (bd->mode & BUILD_MODE_PARAVIRT) ? "pv" :
+ (bd->mode & BUILD_MODE_ENABLE_DM) ? "hvm" :
+ "pvh");
+ }
}
fdt_for_each_subnode(node, fdt, dom_node)
--
2.43.0
^ permalink raw reply related [flat|nested] 23+ messages in thread* [PATCH v5 10/12] x86/hyperlaunch: add memory parsing to domain config
2025-04-24 16:10 [PATCH v5 00/12] Hyperlaunch device tree for dom0 Alejandro Vallejo
` (8 preceding siblings ...)
2025-04-24 16:10 ` [PATCH v5 09/12] x86/hyperlaunch: specify dom0 mode with device tree Alejandro Vallejo
@ 2025-04-24 16:10 ` Alejandro Vallejo
2025-04-24 16:10 ` [PATCH v5 11/12] x86/hyperlaunch: add max vcpu parsing of hyperlaunch device tree Alejandro Vallejo
` (2 subsequent siblings)
12 siblings, 0 replies; 23+ messages in thread
From: Alejandro Vallejo @ 2025-04-24 16:10 UTC (permalink / raw)
To: xen-devel
Cc: Daniel P. Smith, Jan Beulich, Andrew Cooper, Roger Pau Monné,
Anthony PERARD, Michal Orzel, Julien Grall, Stefano Stabellini,
Jason Andryuk, Alejandro Vallejo
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Add three properties, memory, mem-min, and mem-max, to the domain node device
tree parsing to define the memory allocation for a domain. All three fields are
expressed in kb and written as a u64 in the device tree entries.
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
---
v5:
* strncmp() == 0 -> !strncmp()
* Moved the _u64 helper in libfdt-xen.h to fdt.c
---
xen/arch/x86/dom0_build.c | 8 +++++
xen/arch/x86/include/asm/boot-domain.h | 4 +++
xen/arch/x86/setup.c | 5 ++-
xen/common/domain-builder/fdt.c | 46 ++++++++++++++++++++++++++
4 files changed, 62 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 0b467fd4a4..8db24dbc0a 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -627,6 +627,14 @@ int __init construct_dom0(const struct boot_domain *bd)
process_pending_softirqs();
+ /* If param dom0_size was not set and HL config provided memory size */
+ if ( !get_memsize(&dom0_size, ULONG_MAX) && bd->mem_pages )
+ dom0_size.nr_pages = bd->mem_pages;
+ if ( !get_memsize(&dom0_min_size, ULONG_MAX) && bd->min_pages )
+ dom0_min_size.nr_pages = bd->min_pages;
+ if ( !get_memsize(&dom0_max_size, ULONG_MAX) && bd->max_pages )
+ dom0_max_size.nr_pages = bd->max_pages;
+
if ( is_hvm_domain(d) )
rc = dom0_construct_pvh(bd);
else if ( is_pv_domain(d) )
diff --git a/xen/arch/x86/include/asm/boot-domain.h b/xen/arch/x86/include/asm/boot-domain.h
index e316d4bcde..fa8ea1cc66 100644
--- a/xen/arch/x86/include/asm/boot-domain.h
+++ b/xen/arch/x86/include/asm/boot-domain.h
@@ -18,6 +18,10 @@ struct boot_domain {
#define BUILD_MODE_ENABLE_DM (1 << 1) /* HVM | PVH */
uint32_t mode;
+ unsigned long mem_pages;
+ unsigned long min_pages;
+ unsigned long max_pages;
+
struct boot_module *kernel;
struct boot_module *module;
const char *cmdline;
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index d3a4f89a6a..d4f839146f 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -296,7 +296,10 @@ static const char *cmdline_cook(const char *p, const char *loader_name);
struct boot_info __initdata xen_boot_info = {
.loader = "unknown",
.cmdline = "",
- .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = { .domid = DOMID_INVALID } },
+ .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = {
+ .domid = DOMID_INVALID,
+ .max_pages = ULONG_MAX,
+ }},
};
static struct boot_info *__init multiboot_fill_boot_info(
diff --git a/xen/common/domain-builder/fdt.c b/xen/common/domain-builder/fdt.c
index 75f68de448..ff41727ef1 100644
--- a/xen/common/domain-builder/fdt.c
+++ b/xen/common/domain-builder/fdt.c
@@ -7,6 +7,7 @@
#include <xen/init.h>
#include <xen/lib.h>
#include <xen/libfdt/libfdt.h>
+#include <xen/sizes.h>
#include <asm/bootinfo.h>
#include <asm/page.h>
@@ -24,6 +25,16 @@ static int __init fdt_prop_as_u32(const struct fdt_property *prop,
return 0;
}
+static int __init fdt_prop_as_u64(const struct fdt_property *prop,
+ uint64_t *val)
+{
+ if ( !prop || fdt32_to_cpu(prop->len) < sizeof(uint64_t) )
+ return -EINVAL;
+
+ *val = fdt64_to_cpu(*(const fdt64_t *)prop->data);
+ return 0;
+}
+
/*
* Unpacks a "reg" property into its address and size constituents.
*
@@ -256,6 +267,41 @@ static int __init process_domain_node(
(bd->mode & BUILD_MODE_ENABLE_DM) ? "hvm" :
"pvh");
}
+ else if ( !strncmp(prop_name, "memory", name_len) )
+ {
+ uint64_t kb;
+ if ( (rc = fdt_prop_as_u64(prop, &kb)) )
+ {
+ printk(XENLOG_ERR " bad \"memory\" prop on domain %s\n", name);
+ return rc;
+ }
+ bd->mem_pages = PFN_DOWN(kb * SZ_1K);
+ printk(XENLOG_ERR " memory: %lu KiB\n", kb);
+ }
+ else if ( !strncmp(prop_name, "mem-min", name_len) )
+ {
+ uint64_t kb;
+ if ( (rc = fdt_prop_as_u64(prop, &kb)) )
+ {
+ printk(XENLOG_ERR
+ " bad \"mem-min\" prop on domain %s\n", name);
+ return rc;
+ }
+ bd->min_pages = PFN_DOWN(kb * SZ_1K);
+ printk(XENLOG_INFO " min memory: %lu kb\n", kb);
+ }
+ else if ( !strncmp(prop_name, "mem-max", name_len) )
+ {
+ uint64_t kb;
+ if ( (rc = fdt_prop_as_u64(prop, &kb)) )
+ {
+ printk(XENLOG_ERR
+ " bad \"mem-max\" prop on domain %s\n", name);
+ return rc;
+ }
+ bd->max_pages = PFN_DOWN(kb * SZ_1K);
+ printk(XENLOG_INFO " max memory: %lu KiB\n", kb);
+ }
}
fdt_for_each_subnode(node, fdt, dom_node)
--
2.43.0
^ permalink raw reply related [flat|nested] 23+ messages in thread* [PATCH v5 11/12] x86/hyperlaunch: add max vcpu parsing of hyperlaunch device tree
2025-04-24 16:10 [PATCH v5 00/12] Hyperlaunch device tree for dom0 Alejandro Vallejo
` (9 preceding siblings ...)
2025-04-24 16:10 ` [PATCH v5 10/12] x86/hyperlaunch: add memory parsing to domain config Alejandro Vallejo
@ 2025-04-24 16:10 ` Alejandro Vallejo
2025-04-24 16:10 ` [PATCH v5 12/12] x86/hyperlaunch: add capabilities to boot domain Alejandro Vallejo
2025-04-24 22:19 ` [PATCH v5 00/12] Hyperlaunch device tree for dom0 dmkhn
12 siblings, 0 replies; 23+ messages in thread
From: Alejandro Vallejo @ 2025-04-24 16:10 UTC (permalink / raw)
To: xen-devel
Cc: Daniel P. Smith, Jan Beulich, Andrew Cooper, Roger Pau Monné,
Anthony PERARD, Michal Orzel, Julien Grall, Stefano Stabellini,
Jason Andryuk, Alejandro Vallejo, Denis Mukhin
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Introduce the `cpus` property, named as such for dom0less compatibility, that
represents the maximum number of vcpus to allocate for a domain. In the device
tree, it will be encoded as a u32 value.
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
---
xen/arch/x86/dom0_build.c | 3 +++
xen/arch/x86/include/asm/boot-domain.h | 2 ++
xen/common/domain-builder/fdt.c | 11 +++++++++++
3 files changed, 16 insertions(+)
diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 8db24dbc0a..f734104c74 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -635,6 +635,9 @@ int __init construct_dom0(const struct boot_domain *bd)
if ( !get_memsize(&dom0_max_size, ULONG_MAX) && bd->max_pages )
dom0_max_size.nr_pages = bd->max_pages;
+ if ( opt_dom0_max_vcpus_max == UINT_MAX && bd->max_vcpus )
+ opt_dom0_max_vcpus_max = bd->max_vcpus;
+
if ( is_hvm_domain(d) )
rc = dom0_construct_pvh(bd);
else if ( is_pv_domain(d) )
diff --git a/xen/arch/x86/include/asm/boot-domain.h b/xen/arch/x86/include/asm/boot-domain.h
index fa8ea1cc66..969c02a6ea 100644
--- a/xen/arch/x86/include/asm/boot-domain.h
+++ b/xen/arch/x86/include/asm/boot-domain.h
@@ -22,6 +22,8 @@ struct boot_domain {
unsigned long min_pages;
unsigned long max_pages;
+ unsigned int max_vcpus;
+
struct boot_module *kernel;
struct boot_module *module;
const char *cmdline;
diff --git a/xen/common/domain-builder/fdt.c b/xen/common/domain-builder/fdt.c
index ff41727ef1..e90f183481 100644
--- a/xen/common/domain-builder/fdt.c
+++ b/xen/common/domain-builder/fdt.c
@@ -302,6 +302,17 @@ static int __init process_domain_node(
bd->max_pages = PFN_DOWN(kb * SZ_1K);
printk(XENLOG_INFO " max memory: %lu KiB\n", kb);
}
+ else if ( !strncmp(prop_name, "cpus", name_len) )
+ {
+ uint32_t val = UINT32_MAX;
+ if ( (rc = fdt_prop_as_u32(prop, &val)) )
+ {
+ printk(XENLOG_ERR " bad \"cpus\" prop on domain %s\n", name);
+ return rc;
+ }
+ bd->max_vcpus = val;
+ printk(XENLOG_INFO " cpus: %d\n", bd->max_vcpus);
+ }
}
fdt_for_each_subnode(node, fdt, dom_node)
--
2.43.0
^ permalink raw reply related [flat|nested] 23+ messages in thread* [PATCH v5 12/12] x86/hyperlaunch: add capabilities to boot domain
2025-04-24 16:10 [PATCH v5 00/12] Hyperlaunch device tree for dom0 Alejandro Vallejo
` (10 preceding siblings ...)
2025-04-24 16:10 ` [PATCH v5 11/12] x86/hyperlaunch: add max vcpu parsing of hyperlaunch device tree Alejandro Vallejo
@ 2025-04-24 16:10 ` Alejandro Vallejo
2025-04-25 15:32 ` Alejandro Vallejo
2025-04-24 22:19 ` [PATCH v5 00/12] Hyperlaunch device tree for dom0 dmkhn
12 siblings, 1 reply; 23+ messages in thread
From: Alejandro Vallejo @ 2025-04-24 16:10 UTC (permalink / raw)
To: xen-devel
Cc: Daniel P. Smith, Jan Beulich, Andrew Cooper, Roger Pau Monné,
Anthony PERARD, Michal Orzel, Julien Grall, Stefano Stabellini,
Jason Andryuk, Alejandro Vallejo, Denis Mukhin
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Introduce the ability to assign capabilities to a domain via its definition in
device tree. The first capability enabled to select is the control domain
capability. The capability property is a bitfield in both the device tree and
`struct boot_domain`.
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
---
v5:
* Removed BUILD_CAPS, as DOMAIN_CAPS is now in public/bootfdt.h
* Assigned DOMAIN_CAPS_MASK to dom0, rather than only BUILD_CAPS_CONTROL.
* So it also gets hardware+xenstore.
---
xen/arch/x86/include/asm/boot-domain.h | 3 +++
xen/arch/x86/setup.c | 5 ++++-
xen/common/domain-builder/fdt.c | 23 +++++++++++++++++++++++
3 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/include/asm/boot-domain.h b/xen/arch/x86/include/asm/boot-domain.h
index 969c02a6ea..cb5351241a 100644
--- a/xen/arch/x86/include/asm/boot-domain.h
+++ b/xen/arch/x86/include/asm/boot-domain.h
@@ -13,6 +13,9 @@
struct boot_domain {
domid_t domid;
+ /* Bitmap. See DOMAIN_CAPS_MASK for a list */
+ uint32_t capabilities;
+
/* On | Off */
#define BUILD_MODE_PARAVIRT (1 << 0) /* PV | PVH/HVM */
#define BUILD_MODE_ENABLE_DM (1 << 1) /* HVM | PVH */
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index d4f839146f..960e43c785 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -61,6 +61,7 @@
#include <xsm/xsm.h>
+#include <public/bootfdt.h>
#include <public/version.h>
#ifdef CONFIG_COMPAT
#include <compat/platform.h>
@@ -1050,7 +1051,8 @@ static struct domain *__init create_dom0(struct boot_info *bi)
/* Create initial domain. Not d0 for pvshim. */
bd->domid = get_initial_domain_id();
d = domain_create(bd->domid, &dom0_cfg,
- pv_shim ? 0 : CDF_privileged | CDF_hardware);
+ ((bd->capabilities & DOMAIN_CAPS_CONTROL) ? CDF_privileged : 0) |
+ ((bd->capabilities & DOMAIN_CAPS_HARDWARE) ? CDF_hardware : 0));
if ( IS_ERR(d) )
panic("Error creating d%u: %ld\n", bd->domid, PTR_ERR(d));
@@ -1313,6 +1315,7 @@ void asmlinkage __init noreturn __start_xen(void)
i = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
bi->mods[i].type = BOOTMOD_KERNEL;
bi->domains[0].kernel = &bi->mods[i];
+ bi->domains[0].capabilities = pv_shim ? 0 : DOMAIN_CAPS_MASK;
bi->nr_domains = 1;
bi->hyperlaunch_enabled = false;
}
diff --git a/xen/common/domain-builder/fdt.c b/xen/common/domain-builder/fdt.c
index e90f183481..09d2930e16 100644
--- a/xen/common/domain-builder/fdt.c
+++ b/xen/common/domain-builder/fdt.c
@@ -7,6 +7,7 @@
#include <xen/init.h>
#include <xen/lib.h>
#include <xen/libfdt/libfdt.h>
+#include <public/bootfdt.h>
#include <xen/sizes.h>
#include <asm/bootinfo.h>
@@ -313,6 +314,28 @@ static int __init process_domain_node(
bd->max_vcpus = val;
printk(XENLOG_INFO " cpus: %d\n", bd->max_vcpus);
}
+ else if ( !strncmp(prop_name, "capabilities", name_len) )
+ {
+ if ( (rc = fdt_prop_as_u32(prop, &bd->capabilities)) )
+ {
+ printk(XENLOG_ERR
+ " bad \"capabilities\" on domain %s\n", name);
+ return rc;
+ }
+
+ if ( bd->capabilities & ~DOMAIN_CAPS_MASK )
+ {
+ printk(XENLOG_WARNING " unknown capabilities: %#x\n",
+ bd->capabilities & ~DOMAIN_CAPS_MASK);
+
+ bd->capabilities &= DOMAIN_CAPS_MASK;
+ }
+
+ printk(XENLOG_INFO " caps: %s%s%s\n",
+ (bd->capabilities & DOMAIN_CAPS_CONTROL) ? "c" : "",
+ (bd->capabilities & DOMAIN_CAPS_HARDWARE) ? "h" : "",
+ (bd->capabilities & DOMAIN_CAPS_XENSTORE) ? "x" : "");
+ }
}
fdt_for_each_subnode(node, fdt, dom_node)
--
2.43.0
^ permalink raw reply related [flat|nested] 23+ messages in thread* Re: [PATCH v5 12/12] x86/hyperlaunch: add capabilities to boot domain
2025-04-24 16:10 ` [PATCH v5 12/12] x86/hyperlaunch: add capabilities to boot domain Alejandro Vallejo
@ 2025-04-25 15:32 ` Alejandro Vallejo
0 siblings, 0 replies; 23+ messages in thread
From: Alejandro Vallejo @ 2025-04-25 15:32 UTC (permalink / raw)
To: Alejandro Vallejo, xen-devel
Cc: Daniel P. Smith, Jan Beulich, Andrew Cooper, Roger Pau Monné,
Anthony PERARD, Michal Orzel, Julien Grall, Stefano Stabellini,
Jason Andryuk, Denis Mukhin
On Thu Apr 24, 2025 at 5:10 PM BST, Alejandro Vallejo wrote:
> From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
>
> Introduce the ability to assign capabilities to a domain via its definition in
> device tree. The first capability enabled to select is the control domain
> capability. The capability property is a bitfield in both the device tree and
> `struct boot_domain`.
>
> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
> Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
> Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
> Reviewed-by: Denis Mukhin <dmukhin@ford.com>
> ---
> v5:
> * Removed BUILD_CAPS, as DOMAIN_CAPS is now in public/bootfdt.h
> * Assigned DOMAIN_CAPS_MASK to dom0, rather than only BUILD_CAPS_CONTROL.
> * So it also gets hardware+xenstore.
> ---
> xen/arch/x86/include/asm/boot-domain.h | 3 +++
> xen/arch/x86/setup.c | 5 ++++-
> xen/common/domain-builder/fdt.c | 23 +++++++++++++++++++++++
> 3 files changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/include/asm/boot-domain.h b/xen/arch/x86/include/asm/boot-domain.h
> index 969c02a6ea..cb5351241a 100644
> --- a/xen/arch/x86/include/asm/boot-domain.h
> +++ b/xen/arch/x86/include/asm/boot-domain.h
> @@ -13,6 +13,9 @@
> struct boot_domain {
> domid_t domid;
>
> + /* Bitmap. See DOMAIN_CAPS_MASK for a list */
> + uint32_t capabilities;
> +
> /* On | Off */
> #define BUILD_MODE_PARAVIRT (1 << 0) /* PV | PVH/HVM */
> #define BUILD_MODE_ENABLE_DM (1 << 1) /* HVM | PVH */
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index d4f839146f..960e43c785 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -61,6 +61,7 @@
>
> #include <xsm/xsm.h>
>
> +#include <public/bootfdt.h>
> #include <public/version.h>
> #ifdef CONFIG_COMPAT
> #include <compat/platform.h>
> @@ -1050,7 +1051,8 @@ static struct domain *__init create_dom0(struct boot_info *bi)
> /* Create initial domain. Not d0 for pvshim. */
> bd->domid = get_initial_domain_id();
Self commenting that I missed XEN_DOMCTL_CDF_iommu being passed if
iommu_enabled is set (out of context, a few lines above). That should be
gated on DOMAIN_CAPS_HARDWARE being set too. Just spotted it when
rebasing the RFC series from Daniel.
Cheers,
Alejandro
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v5 00/12] Hyperlaunch device tree for dom0
2025-04-24 16:10 [PATCH v5 00/12] Hyperlaunch device tree for dom0 Alejandro Vallejo
` (11 preceding siblings ...)
2025-04-24 16:10 ` [PATCH v5 12/12] x86/hyperlaunch: add capabilities to boot domain Alejandro Vallejo
@ 2025-04-24 22:19 ` dmkhn
2025-04-25 11:58 ` Alejandro Vallejo
12 siblings, 1 reply; 23+ messages in thread
From: dmkhn @ 2025-04-24 22:19 UTC (permalink / raw)
To: Alejandro Vallejo
Cc: xen-devel, Andrew Cooper, Anthony PERARD, Michal Orzel,
Jan Beulich, Julien Grall, Roger Pau Monné,
Stefano Stabellini, Bertrand Marquis
On Thu, Apr 24, 2025 at 05:10:10PM +0100, Alejandro Vallejo wrote:
> Hi,
>
> v4: https://lore.kernel.org/xen-devel/20250417124844.11143-1-agarciav@amd.com/
> v3: https://lore.kernel.org/xen-devel/20250408160802.49870-1-agarciav@amd.com/
> v2: https://lore.kernel.org/xen-devel/20241226165740.29812-1-dpsmith@apertussolutions.com/
> v1: https://lore.kernel.org/xen-devel/20241123182044.30687-1-dpsmith@apertussolutions.com/
>
> ========= Original cover letter:
>
> The Hyperlaunch device tree for dom0 series is the second split out for the
> introduction of the Hyperlaunch domain builder logic. These changes focus on
> introducing the ability to express a domain configuration that is then used to
> populate the struct boot_domain structure for dom0. This ability to express a
> domain configuration provides the next step towards a general domain builder.
>
> The splitting of Hyperlaunch into a set of series are twofold, to reduce the
> effort in reviewing a much larger series, and to reduce the effort in handling
> the knock-on effects to the construction logic from requested review changes.
>
>
>
> Alejandro Vallejo (1):
> x86/hyperlaunch: Add helpers to locate multiboot modules
>
> Daniel P. Smith (11):
> kconfig: introduce domain builder config options
> common/hyperlaunch: introduce the domain builder
> x86/hyperlaunch: initial support for hyperlaunch device tree
> x86/hyperlaunch: locate dom0 kernel with hyperlaunch
> x86/hyperlaunch: obtain cmdline from device tree
> x86/hyperlaunch: locate dom0 initrd with hyperlaunch
> x86/hyperlaunch: add domain id parsing to domain config
> x86/hyperlaunch: specify dom0 mode with device tree
> x86/hyperlaunch: add memory parsing to domain config
> x86/hyperlaunch: add max vcpu parsing of hyperlaunch device tree
> x86/hyperlaunch: add capabilities to boot domain
One general comment w.r.t. naming notation in:
xen/common/domain-builder/fdt.c
xen/common/domain-builder/fdt.h
Sorry, overlooked that earlier.
What do you think about using fdt_<something> notation for all functions in
fdt.{c,h}?
For example:
s/detect_fdt_kind/fdt_detect_hyperlauch_node/
s/find_hyperlaunch_node/fdt_find_hyperlauch_node/
s/walk_hyperlaunch_fdt/fdt_walk_hyperlauch_node/
s/process_domain_node/fdt_process_hyperlauch_node/
Other than that:
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
for the series.
>
> xen/arch/x86/dom0_build.c | 11 +
> xen/arch/x86/include/asm/boot-domain.h | 14 +
> xen/arch/x86/include/asm/bootinfo.h | 10 +-
> xen/arch/x86/setup.c | 64 +++-
> xen/common/Kconfig | 2 +
> xen/common/Makefile | 1 +
> xen/common/domain-builder/Kconfig | 15 +
> xen/common/domain-builder/Makefile | 2 +
> xen/common/domain-builder/core.c | 86 +++++
> xen/common/domain-builder/fdt.c | 512 +++++++++++++++++++++++++
> xen/common/domain-builder/fdt.h | 40 ++
> xen/include/xen/domain-builder.h | 37 ++
> xen/include/xen/libfdt/libfdt-xen.h | 23 ++
> 13 files changed, 800 insertions(+), 17 deletions(-)
> create mode 100644 xen/common/domain-builder/Kconfig
> create mode 100644 xen/common/domain-builder/Makefile
> create mode 100644 xen/common/domain-builder/core.c
> create mode 100644 xen/common/domain-builder/fdt.c
> create mode 100644 xen/common/domain-builder/fdt.h
> create mode 100644 xen/include/xen/domain-builder.h
>
> --
> 2.43.0
>
>
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [PATCH v5 00/12] Hyperlaunch device tree for dom0
2025-04-24 22:19 ` [PATCH v5 00/12] Hyperlaunch device tree for dom0 dmkhn
@ 2025-04-25 11:58 ` Alejandro Vallejo
2025-04-25 14:48 ` dmkhn
0 siblings, 1 reply; 23+ messages in thread
From: Alejandro Vallejo @ 2025-04-25 11:58 UTC (permalink / raw)
To: dmkhn
Cc: xen-devel, Andrew Cooper, Anthony PERARD, Michal Orzel,
Jan Beulich, Julien Grall, Roger Pau Monné,
Stefano Stabellini, Bertrand Marquis
On Thu Apr 24, 2025 at 11:19 PM BST, dmkhn wrote:
> On Thu, Apr 24, 2025 at 05:10:10PM +0100, Alejandro Vallejo wrote:
>> Hi,
>>
>> v4: https://lore.kernel.org/xen-devel/20250417124844.11143-1-agarciav@amd.com/
>> v3: https://lore.kernel.org/xen-devel/20250408160802.49870-1-agarciav@amd.com/
>> v2: https://lore.kernel.org/xen-devel/20241226165740.29812-1-dpsmith@apertussolutions.com/
>> v1: https://lore.kernel.org/xen-devel/20241123182044.30687-1-dpsmith@apertussolutions.com/
>>
>> ========= Original cover letter:
>>
>> The Hyperlaunch device tree for dom0 series is the second split out for the
>> introduction of the Hyperlaunch domain builder logic. These changes focus on
>> introducing the ability to express a domain configuration that is then used to
>> populate the struct boot_domain structure for dom0. This ability to express a
>> domain configuration provides the next step towards a general domain builder.
>>
>> The splitting of Hyperlaunch into a set of series are twofold, to reduce the
>> effort in reviewing a much larger series, and to reduce the effort in handling
>> the knock-on effects to the construction logic from requested review changes.
>>
>>
>>
>> Alejandro Vallejo (1):
>> x86/hyperlaunch: Add helpers to locate multiboot modules
>>
>> Daniel P. Smith (11):
>> kconfig: introduce domain builder config options
>> common/hyperlaunch: introduce the domain builder
>> x86/hyperlaunch: initial support for hyperlaunch device tree
>> x86/hyperlaunch: locate dom0 kernel with hyperlaunch
>> x86/hyperlaunch: obtain cmdline from device tree
>> x86/hyperlaunch: locate dom0 initrd with hyperlaunch
>> x86/hyperlaunch: add domain id parsing to domain config
>> x86/hyperlaunch: specify dom0 mode with device tree
>> x86/hyperlaunch: add memory parsing to domain config
>> x86/hyperlaunch: add max vcpu parsing of hyperlaunch device tree
>> x86/hyperlaunch: add capabilities to boot domain
>
> One general comment w.r.t. naming notation in:
>
> xen/common/domain-builder/fdt.c
> xen/common/domain-builder/fdt.h
>
> Sorry, overlooked that earlier.
>
> What do you think about using fdt_<something> notation for all functions in
> fdt.{c,h}?
>
> For example:
>
> s/detect_fdt_kind/fdt_detect_hyperlauch_node/
^
kind?
>
> s/find_hyperlaunch_node/fdt_find_hyperlauch_node/
>
> s/walk_hyperlaunch_fdt/fdt_walk_hyperlauch_node/
>
> s/process_domain_node/fdt_process_hyperlauch_node/
^
domain?
Assuming the two nits above are mistakes on copy-paste, it sounds
reasonable. I'll wait for some acks on the rest and resend with those
adjustments if needed.
>
> Other than that:
>
> Reviewed-by: Denis Mukhin <dmukhin@ford.com>
>
> for the series.
Thanks a lot!
Cheers,
Alejandro
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [PATCH v5 00/12] Hyperlaunch device tree for dom0
2025-04-25 11:58 ` Alejandro Vallejo
@ 2025-04-25 14:48 ` dmkhn
0 siblings, 0 replies; 23+ messages in thread
From: dmkhn @ 2025-04-25 14:48 UTC (permalink / raw)
To: Alejandro Vallejo
Cc: xen-devel, Andrew Cooper, Anthony PERARD, Michal Orzel,
Jan Beulich, Julien Grall, Roger Pau Monné,
Stefano Stabellini, Bertrand Marquis
On Fri, Apr 25, 2025 at 12:58:01PM +0100, Alejandro Vallejo wrote:
> On Thu Apr 24, 2025 at 11:19 PM BST, dmkhn wrote:
> > On Thu, Apr 24, 2025 at 05:10:10PM +0100, Alejandro Vallejo wrote:
> >> Hi,
> >>
> >> v4: https://lore.kernel.org/xen-devel/20250417124844.11143-1-agarciav@amd.com/
> >> v3: https://lore.kernel.org/xen-devel/20250408160802.49870-1-agarciav@amd.com/
> >> v2: https://lore.kernel.org/xen-devel/20241226165740.29812-1-dpsmith@apertussolutions.com/
> >> v1: https://lore.kernel.org/xen-devel/20241123182044.30687-1-dpsmith@apertussolutions.com/
> >>
> >> ========= Original cover letter:
> >>
> >> The Hyperlaunch device tree for dom0 series is the second split out for the
> >> introduction of the Hyperlaunch domain builder logic. These changes focus on
> >> introducing the ability to express a domain configuration that is then used to
> >> populate the struct boot_domain structure for dom0. This ability to express a
> >> domain configuration provides the next step towards a general domain builder.
> >>
> >> The splitting of Hyperlaunch into a set of series are twofold, to reduce the
> >> effort in reviewing a much larger series, and to reduce the effort in handling
> >> the knock-on effects to the construction logic from requested review changes.
> >>
> >>
> >>
> >> Alejandro Vallejo (1):
> >> x86/hyperlaunch: Add helpers to locate multiboot modules
> >>
> >> Daniel P. Smith (11):
> >> kconfig: introduce domain builder config options
> >> common/hyperlaunch: introduce the domain builder
> >> x86/hyperlaunch: initial support for hyperlaunch device tree
> >> x86/hyperlaunch: locate dom0 kernel with hyperlaunch
> >> x86/hyperlaunch: obtain cmdline from device tree
> >> x86/hyperlaunch: locate dom0 initrd with hyperlaunch
> >> x86/hyperlaunch: add domain id parsing to domain config
> >> x86/hyperlaunch: specify dom0 mode with device tree
> >> x86/hyperlaunch: add memory parsing to domain config
> >> x86/hyperlaunch: add max vcpu parsing of hyperlaunch device tree
> >> x86/hyperlaunch: add capabilities to boot domain
> >
> > One general comment w.r.t. naming notation in:
> >
> > xen/common/domain-builder/fdt.c
> > xen/common/domain-builder/fdt.h
> >
> > Sorry, overlooked that earlier.
> >
> > What do you think about using fdt_<something> notation for all functions in
> > fdt.{c,h}?
> >
> > For example:
> >
> > s/detect_fdt_kind/fdt_detect_hyperlauch_node/
> ^
> kind?
> >
> > s/find_hyperlaunch_node/fdt_find_hyperlauch_node/
> >
> > s/walk_hyperlaunch_fdt/fdt_walk_hyperlauch_node/
> >
> > s/process_domain_node/fdt_process_hyperlauch_node/
> ^
> domain?
>
> Assuming the two nits above are mistakes on copy-paste, it sounds
> reasonable. I'll wait for some acks on the rest and resend with those
> adjustments if needed.
Sounds good!
Yep, my point is let's use prefix for consistency.
>
> >
> > Other than that:
> >
> > Reviewed-by: Denis Mukhin <dmukhin@ford.com>
> >
> > for the series.
>
> Thanks a lot!
>
> Cheers,
> Alejandro
^ permalink raw reply [flat|nested] 23+ messages in thread