On Tue, 24 Feb 2026, BALATON Zoltan wrote:
On Tue, 24 Feb 2026, Ruslan Ruslichenko wrote:
On Tue, Feb 24, 2026 at 12:55 AM BALATON Zoltan <[email protected]> wrote:
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.
Here are few specific examples:
1. DTS compatibles and QOM type names are all different.
Using Linux device tree would require to maintain some massive hardcoded
mapping
even for devices that otherwise don't require any special handling.
Bernhard's patches had the same issue and solved it by adding subclasses with
names matching the dtb. I think that would not work but a better approach is
to allow alias names for devices (we already have machine name aliases I
thought something similar for devices) that would solve this issue without
too much additional complexity. Then the device would just need an additional
line registering an alias name to match the dtb name (or more of different
machines have different compatible names).
2. Object properties. We would probably need to make sure there is no
conflicts
and all properties are either ignored by Linux drivers or have exactly
the same meaning.
3. Devices mapped to Secure Firmwares only. Those are not accessible by
Linux
and trying to initialize them from the Linux kernel would cause memory
aborts.
4. Connecting devices to backends such as serial, block devices, etc.
We need to specify corresponding 'chardev' and 'driver' properties.
This is probably not part of the machine but a specific invocation so these
should be specified on the command line and not in the machine definion.
5. Interrupt wiring. Some hardware lines are transparent to Linux, but need
be
wired by QEMU. For example, interrupt controllers are wired to CPUs, etc.
If we would want to initialize it from dts eventually, this would need to
be
passed somehow.
Overall, my understanding is Device models typically need to support
booting existing
OS images and device trees from regular platform builds.
And at least due points 2-4, we cannot use them directly.
Some of the points may be solved other than modifying dtb but some may indeed
need extensions so a separate hw-dtb may be needed in more complex cases.
Since we still need to modify the device tree for QEMU anyway, having
support
for unified DTS doesn't really make sense.
However it may be worthwile to try keeping the modifications minimal so for
simple machines like the e500-ppc that has no secure world or other things
not described by the normal dtb it could just use the regular dtb and the
hw-dtb option would be optional for more complex machines that need it.
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?
Most devices can be created from generic code. Supporting one common
approach to initialize some specific device class would be simpler and more
maintainable than writing a custom FDT handler logic within each device
model.
I think putting device specific knowledge in generic code is against the
object oriented design of QEMU and would be less maintainable because it
would not belong to the device maintainers that way. If you have common code
for some device classes then those devices probably have a superclass where
this code could be put. The problem of mapping property names to device
specific properties could also be done easier within a device model which has
better knowledge of the device and then we would not need a global table
mapping these. So while at first look it may seem more fragmented putting
some logic in devices instead of a central place it's better fits the object
model and groups device specific logic in the device model which is more
maintainable than a global mapping that does not belong to any device but
touches several unrelated devices.
It does not help that Google randomly refuses my emails saying it's spam
if I cc it to more than one gmail user. See my reply above if you've
missed the previous mail. Hopefully this gets through.
Regards,
BALATON Zoltan
