On Mon, 23 Feb 2026, Ruslan Ruslichenko wrote:
On Mon, Feb 23, 2026 at 2:23 PM Alex Bennée <[email protected]> wrote:
Thomas Huth <[email protected]> writes:
Hi!
On 19/02/2026 15.48, Ruslan Ruslichenko wrote:
From: Ruslan Ruslichenko <[email protected]>
Add new '-hw-dtb' command-line option and corresponding
MachineState property.
The 'hw-dtb' option allows to specify a Device tree
binary with hardware description which Qemu should
emulate.
Signed-off-by: Ruslan Ruslichenko <[email protected]>
---
hw/core/machine.c | 19 +++++++++++++++++++
include/hw/core/boards.h | 1 +
qemu-options.hx | 9 +++++++++
system/vl.c | 3 +++
4 files changed, 32 insertions(+)
diff --git a/hw/core/machine.c b/hw/core/machine.c
index d4ef620c17..affd24cd49 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -363,6 +363,20 @@ static void machine_set_dtb(Object *obj, const char
*value, Error **errp)
ms->dtb = g_strdup(value);
}
+static char *machine_get_hw_dtb(Object *obj, Error **errp)
+{
+ MachineState *ms = MACHINE(obj);
+
+ return g_strdup(ms->hw_dtb);
+}
+
+static void machine_set_hw_dtb(Object *obj, const char *value, Error **errp)
+{
+ MachineState *ms = MACHINE(obj);
+
+ ms->hw_dtb = g_strdup(value);
+}
+
static char *machine_get_dumpdtb(Object *obj, Error **errp)
{
MachineState *ms = MACHINE(obj);
@@ -1145,6 +1159,11 @@ static void machine_class_init(ObjectClass *oc, const
void *data)
object_class_property_set_description(oc, "dtb",
"Linux kernel device tree file");
+ object_class_property_add_str(oc, "hw-dtb",
+ machine_get_hw_dtb, machine_set_hw_dtb);
+ object_class_property_set_description(oc, "hw-dtb",
+ "A device tree binary used to describe the hardware to QEMU");
Do the hardware dtbs differ from the ones that are passed to the Linux
kernel? If not, I think you likely could use the existing "dtb"
property for your new feature?
They have to - the normal DTB cannot define the whole system because its
only concerned with reporting what the kernel can see to the kernel and
not defining the whole system including what the firmware sees.
Yes, Indeed.
Normal DTB was explored, but there is not enough information to create
QEMU models from it.
Thus we need to have a separate device tree.
What additional data is needed that's not present in dtb from firmware and
what if that additional data is passed to the kernel? I think the kernel
would just ignore the additional data that it doesn't need so one dtb
might be enough even if it has to be more detailed than what the kernel
normally gets. If that works we don't need a separate option.
This series seems to be more complex than Bernhard's e500-fdt experiment
(I've linked to that in
<https://lists.nongnu.org/archive/html/qemu-devel/2026-01/msg05470.html>)
Bernhard's patch only added minimal support for creating devices from fdt
and then put additional logic in the devices instead of handling them in
generic code. Would such an approach lead to simpler fdt handling? If not
why is the additional complexity needed?
Regards,
BALATON Zoltan
