On Wed, Feb 25, 2026 at 1:07 AM BALATON Zoltan <[email protected]> wrote: > > 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.
In fact, machine code now decides which device tree binary to pass to the generic fdt parser. So e500-ppc can indeed use a normal dtb instead and if corresponding aliases are registered then the machine should be created with the fdt_generic framework too. However, for more complex cases we would indeed need HW dtb. > > > >>> 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. > Currently, there are only a few special cases for serial, blockdev type devices to set up their properties, but no awareness about any device class. Even this may probably be improved to be more generic in future too. All other properties are set without any specific mapping to device class, so the parsing logic is generic. The complexity exists because fdt_generic handles the logic for machine construction, such as creating custom memory regions, mapping devices to these regions, and parsing irq-maps. Specifically, this generic memory mapping logic was required to instantiate secure devices and create the correct address space mapping for the PCIe bus in order to build the sbsa-ref example machine. > 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 -- BR, Ruslan Ruslichenko
