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. 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. 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. Since we still need to modify the device tree for QEMU anyway, having support for unified DTS doesn't really make sense. > 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. > Regards, > BALATON Zoltan -- BR, Ruslan Ruslichenko
