From: Ruslan Ruslichenko <Ruslan_Ruslichenko@epam.com>

This patch series introduces new ARM machine model, arm-generic-fdt, and the underlying infrastructure required to instantiate a QEMU machine from a Device Tree.

Origin
This feature originates from AMD QEMU repository and was originally developed by AMD.
The sources available by link: https://github.com/Xilinx/qemu.

Motivation
Currently, adding support for a new ARM board in QEMU required writing a dedicated C source file to define the memory map, instantiate devices, and wire interrupts.
Any modification to board configuration requires a corresponding change in the source code and rebuild of the QEMU binary.

This series introduce alternative approach to define board configuration via a Device Tree. The new arm-generic-fdt machine parses DTB at runtime to dynamically construct system topology.

Beyond providing more flexible board creation, the series provides the infrastructure needed to enable Hardware Co-Simulation workflows in future by using Remote-Port protocol:
https://mail.gnu.org/archive/html/qemu-devel/2025-12/msg02121.html.
In mixed simulation environments - where QEMU emulates CPU subsystem and external simulator (such as SystemC) handles custom logic - memory map and interrupt lines may need to be changed depending on external hardware configuration.

Implementation overview
The series implements FDT loading framework itself, which is capable of:
- Parsing and creating device models
- Set properties for them from a device tree
- Connect IRQs for SysBus devices
- Map memory regions for IO device or system RAM.

NOTE: The GPIO wiring for non-SysBus devices would be added in future patch series.

Patch Summary
- hw/core: Add Generic FDT parsing infrastructure and utility functions
- hw/arm: Add the arm-generic-machine model
- hw/core/sysbus: Add IO memory mapping for standard SysBus devices
- system/memory: Allow MemoryRegions to be configured from FDT
- hw/intc: Add FDT support for ARM GIC (IRQ translation and default wiring)
- target/arm: Add FDT support for CPU timers

Testing
Testing performed used Yocto core-image-minimal rootfs and kernel image.

The hardware description Device tree (used with '-hw-dtb' option) can be found here: https://gist.github.com/ruslichenkor/19a1b7d937dbf889190e670cb677e43e#file-arm64-virt-hw-dts

The guest device tree (used with standard '-dtb' option) can be found here: https://gist.github.com/ruslichenkor/19a1b7d937dbf889190e670cb677e43e#file-arm64-virt-guest-dts

Execute command itself:

./qemu-system-aarch64 \
    -machine arm-generic-fdt \
    -hw-dtb arm64-virt-hw.dtb \
    -dtb arm64-virt-guest.dtb \
    -cpu cortex-a57 -smp 4 -m 256 \
    -drive id=disk0,file=./core-image-minimal-qemuarm64.rootfs-20251218190831.ext4,if=none,format=raw \
    -device virtio-blk-device,drive=disk0 \
    -kernel ./Image \
    -nographic \
    -append 'root=/dev/vda console=ttyAMA0 mem=256M swiotlb=0 '

Ruslan Ruslichenko (27):
  system/device_tree: update qemu_fdt_getprop/_cell
  system/device_tree: add few parsing and traversal helpers
  util/log: add log entry for fdt generic utils
  hw/core: introduce generic FDT device model registry
  hw/core/fdt_generic: implement FDT machine creation helpers
  hw/core/fdt_generic: add cpu clusters management
  hw/core/fdt_generic_util: implement main fdt parse routine
  hw/core/fdt_generic_util: implement fdt_init_qdev
  hw/core/fdt_generic_util: initilize qdev properties from fdt
  hw/core/fdt_generic_util: actually realize device
  hw/core/fdt_generic_util: add TYPE_FDT_GENERIC_MMAP
  hw/core/fdt_generic_util: add TYPE_FDT_GENERIC_INTC
  hw/core/fdt_generic_util: implement fdt_get_irq/_info API
  hw/core/fdt_generic_util: map device memory
  hw/core/fdt_generic_util: Connect device irqs
  hw/core/fdt_generic_util: realize cpu clusters
  hw/core: add fdt_generic to the build
  hw/core/machine: add '-hw-dtb' option for machine
  hw/arm: add generic ARM machine initialized by FDT
  hw/core/sysbus: implement FDT_GENERIC_MMAP_CLASS interface
  hw/intc/arm_gic: implement FDT_GENERIC_INTC and fdt support
  target/arm/cpu: add fdt support for armv8-timer
  qom/object: export object_resolve_link()
  system/memory: add setters for MemoryRegion properties
  system/memory: implement FDT_GENERIC_MMAP interface
  hw/core/fdt_generic_util: initialize serial devices
  system/memory: add QOM aliases for fdt support

 hw/arm/arm_generic_fdt.c           |  166 ++++
 hw/arm/boot.c                      |    8 +-
 hw/arm/meson.build                 |    2 +
 hw/arm/raspi4b.c                   |    8 +-
 hw/arm/vexpress.c                  |    4 +-
 hw/arm/xlnx-zcu102.c               |    3 +-
 hw/core/fdt_generic.c              |  286 ++++++
 hw/core/fdt_generic_util.c         | 1349 ++++++++++++++++++++++++++++
 hw/core/machine.c                  |   19 +
 hw/core/meson.build                |    2 +
 hw/core/sysbus.c                   |   28 +
 hw/intc/arm_gic.c                  |   32 +
 hw/intc/arm_gic_common.c           |   50 ++
 include/hw/core/boards.h           |    1 +
 include/hw/core/fdt_generic.h      |  127 +++
 include/hw/core/fdt_generic_util.h |  140 +++
 include/qemu/log.h                 |    1 +
 include/qom/object.h               |   12 +
 include/system/device_tree.h       |   62 +-
 qemu-options.hx                    |    9 +
 qom/object.c                       |    2 +-
 system/device_tree.c               |  236 ++++-
 system/memory.c                    |  248 ++++-
 system/vl.c                        |    3 +
 target/arm/cpu.c                   |  115 +++
 util/log.c                         |    1 +
 26 files changed, 2875 insertions(+), 39 deletions(-)
 create mode 100644 hw/arm/arm_generic_fdt.c
 create mode 100644 hw/core/fdt_generic.c
 create mode 100644 hw/core/fdt_generic_util.c
 create mode 100644 include/hw/core/fdt_generic.h
 create mode 100644 include/hw/core/fdt_generic_util.h

-- 
2.43.0

On Mon, 26 Jan 2026 at 17:43, Ruslan Ruslichenko
<ruslichenko.r@gmail.com> wrote:
>
> From: Ruslan Ruslichenko <Ruslan_Ruslichenko@epam.com>
>
> This patch series introduces new ARM machine model, arm-generic-fdt, and the underlying infrastructure required to instantiate a QEMU machine from a Device Tree.

I'm afraid this has been a feature that has been suggested from
time to time, but which I don't think is workable in general.

Device tree files are designed to provide enough information to
the guest kernel to allow it to find non-probeable hardware. They
are not designed to provide enough information to QEMU to allow
it to create and wire up all the hardware present on the system.

There are specific niches where it can be made to work -- I think
Xilinx have or had a setup where they were generating an FPGA
model and a device tree and a guest kernel all from the same
single data source, so they could put everything necessary into
the dtb, for example -- but I don't think it works in the
general case. As one simple example, the DTB doesn't generally
have any information about how the Secure world works in an Arm
system, because Linux doesn't care about the Secure world. It
also doesn't usually have information that the guest OS can
probe for itself at runtime.

There has been periodic discussion of more flexible user-driven
board creation, but that has generally been with the idea of using
the QMP monitor to orchestrate creation and connection of device
models.

thanks
-- PMM

On Tue, Jan 27, 2026 at 11:03 AM Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Mon, 26 Jan 2026 at 17:43, Ruslan Ruslichenko
> <ruslichenko.r@gmail.com> wrote:
> >
> > From: Ruslan Ruslichenko <Ruslan_Ruslichenko@epam.com>
> >
> > This patch series introduces new ARM machine model, arm-generic-fdt, and the underlying infrastructure required to instantiate a QEMU machine from a Device Tree.
>
> I'm afraid this has been a feature that has been suggested from
> time to time, but which I don't think is workable in general.
>
> Device tree files are designed to provide enough information to
> the guest kernel to allow it to find non-probeable hardware. They
> are not designed to provide enough information to QEMU to allow
> it to create and wire up all the hardware present on the system.
>
> There are specific niches where it can be made to work -- I think
> Xilinx have or had a setup where they were generating an FPGA
> model and a device tree and a guest kernel all from the same
> single data source, so they could put everything necessary into
> the dtb, for example -- but I don't think it works in the
> general case. As one simple example, the DTB doesn't generally
> have any information about how the Secure world works in an Arm
> system, because Linux doesn't care about the Secure world. It
> also doesn't usually have information that the guest OS can
> probe for itself at runtime.
>
> There has been periodic discussion of more flexible user-driven
> board creation, but that has generally been with the idea of using
> the QMP monitor to orchestrate creation and connection of device
> models.
>
I agree that a guest Device Tree is insufficient for describing a
complete QEMU machine model.
However, we separate the guest configuration from the machine
definition. The -hw-dtb option allows the user to provide a
QEMU-specific system description.
Those hw-dtb would not be passed to Linux Guest VM.

The fact that this workflow has been successfully used in production
by AMD/Xilinx demonstrates that FDT is a feasible format.

In contrast, QMP usage may end up even more complex and less
maintainable for the task of full system modeling.
To my understanding, this would need to generate too long configs,
which may eventually require some intermediate format by itself.

I am proposing to use FDT as a serialization format to describe a
machine configuration. Theoretically we can use other formats, like
XML, but in my opinion FDT perfectly matches the requirements.

BR,
Ruslan Ruslichenko


> thanks
> -- PMM

Ruslan Ruslichenko <ruslichenko.r@gmail.com> writes:

> On Tue, Jan 27, 2026 at 11:03 AM Peter Maydell <peter.maydell@linaro.org> wrote:
>>
>> On Mon, 26 Jan 2026 at 17:43, Ruslan Ruslichenko
>> <ruslichenko.r@gmail.com> wrote:
>> >
>> > From: Ruslan Ruslichenko <Ruslan_Ruslichenko@epam.com>
>> >
>> > This patch series introduces new ARM machine model, arm-generic-fdt, and the underlying infrastructure required to instantiate a QEMU machine from a Device Tree.
>>
>> I'm afraid this has been a feature that has been suggested from
>> time to time, but which I don't think is workable in general.
>>
>> Device tree files are designed to provide enough information to
>> the guest kernel to allow it to find non-probeable hardware. They
>> are not designed to provide enough information to QEMU to allow
>> it to create and wire up all the hardware present on the system.
>>
>> There are specific niches where it can be made to work -- I think
>> Xilinx have or had a setup where they were generating an FPGA
>> model and a device tree and a guest kernel all from the same
>> single data source, so they could put everything necessary into
>> the dtb, for example -- but I don't think it works in the
>> general case. As one simple example, the DTB doesn't generally
>> have any information about how the Secure world works in an Arm
>> system, because Linux doesn't care about the Secure world. It
>> also doesn't usually have information that the guest OS can
>> probe for itself at runtime.
>>
>> There has been periodic discussion of more flexible user-driven
>> board creation, but that has generally been with the idea of using
>> the QMP monitor to orchestrate creation and connection of device
>> models.
>>
> I agree that a guest Device Tree is insufficient for describing a
> complete QEMU machine model.
> However, we separate the guest configuration from the machine
> definition. The -hw-dtb option allows the user to provide a
> QEMU-specific system description.
> Those hw-dtb would not be passed to Linux Guest VM.
>
> The fact that this workflow has been successfully used in production
> by AMD/Xilinx demonstrates that FDT is a feasible format.

Where are the extensions to the FDT used for hw-dtb documented? How does
it deal with PCI devices and the Secure world?

> In contrast, QMP usage may end up even more complex and less
> maintainable for the task of full system modeling.
> To my understanding, this would need to generate too long configs,
> which may eventually require some intermediate format by itself.
>
> I am proposing to use FDT as a serialization format to describe a
> machine configuration. Theoretically we can use other formats, like
> XML, but in my opinion FDT perfectly matches the requirements.

The QMP interface is self-documenting and introspectable and used for
the management of QEMU including things like hotplug. It is also QOM
aware so a natural fit for dealing with the underlying QOM machinery.

Previous discussions have entertained the idea of making the parsing of
hw-dtb an external script which would then translate into QMP commands
to build up the machine.

>
> BR,
> Ruslan Ruslichenko
>
>
>> thanks
>> -- PMM

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

On Wed, Jan 28, 2026 at 11:48 AM Alex Bennée <alex.bennee@linaro.org> wrote:

> Ruslan Ruslichenko <ruslichenko.r@gmail.com> writes:
>
> > On Tue, Jan 27, 2026 at 11:03 AM Peter Maydell <peter.maydell@linaro.org>
> wrote:
> >>
> >> On Mon, 26 Jan 2026 at 17:43, Ruslan Ruslichenko
> >> <ruslichenko.r@gmail.com> wrote:
> >> >
> >> > From: Ruslan Ruslichenko <Ruslan_Ruslichenko@epam.com>
> >> >
> >> > This patch series introduces new ARM machine model, arm-generic-fdt,
> and the underlying infrastructure required to instantiate a QEMU machine
> from a Device Tree.
> >>
> >> I'm afraid this has been a feature that has been suggested from
> >> time to time, but which I don't think is workable in general.
> >>
> >> Device tree files are designed to provide enough information to
> >> the guest kernel to allow it to find non-probeable hardware. They
> >> are not designed to provide enough information to QEMU to allow
> >> it to create and wire up all the hardware present on the system.
> >>
> >> There are specific niches where it can be made to work -- I think
> >> Xilinx have or had a setup where they were generating an FPGA
> >> model and a device tree and a guest kernel all from the same
> >> single data source, so they could put everything necessary into
> >> the dtb, for example -- but I don't think it works in the
> >> general case. As one simple example, the DTB doesn't generally
> >> have any information about how the Secure world works in an Arm
> >> system, because Linux doesn't care about the Secure world. It
> >> also doesn't usually have information that the guest OS can
> >> probe for itself at runtime.
> >>
> >> There has been periodic discussion of more flexible user-driven
> >> board creation, but that has generally been with the idea of using
> >> the QMP monitor to orchestrate creation and connection of device
> >> models.
> >>
> > I agree that a guest Device Tree is insufficient for describing a
> > complete QEMU machine model.
> > However, we separate the guest configuration from the machine
> > definition. The -hw-dtb option allows the user to provide a
> > QEMU-specific system description.
> > Those hw-dtb would not be passed to Linux Guest VM.
> >
> > The fact that this workflow has been successfully used in production
> > by AMD/Xilinx demonstrates that FDT is a feasible format.
>
> Where are the extensions to the FDT used for hw-dtb documented? How does
> it deal with PCI devices and the Secure world?
>
>

Hi,

When we first started using this, we tried using the kernel bindings but as
people have already noted on this thread those are not a good fit. So we
changed the approach to something more like a 1:1 mapping between FDT and
QOM. FDT compatible properties match on QOM device names, properties are
set more or less 1:1 with some exceptions.

Interconnects and TZ are modelled by instantiating memory regions, mapping
the selected set of "target" devices and connecting bus masters (CPUs or
DMA) "memory" links.
In addition to that, memory transaction attributes can be used for devices
that differentiate things on a per transaction basis.
This is all the same as you would do in C code with QOM/Qdev.

PCI is modelled the same way as with QOM/qdev.

Cheers,
Edgar


> > In contrast, QMP usage may end up even more complex and less
> > maintainable for the task of full system modeling.
> > To my understanding, this would need to generate too long configs,
> > which may eventually require some intermediate format by itself.
> >
> > I am proposing to use FDT as a serialization format to describe a
> > machine configuration. Theoretically we can use other formats, like
> > XML, but in my opinion FDT perfectly matches the requirements.
>
> The QMP interface is self-documenting and introspectable and used for
> the management of QEMU including things like hotplug. It is also QOM
> aware so a natural fit for dealing with the underlying QOM machinery.
>
> Previous discussions have entertained the idea of making the parsing of
> hw-dtb an external script which would then translate into QMP commands
> to build up the machine.
>
> >
> > BR,
> > Ruslan Ruslichenko
> >
> >
> >> thanks
> >> -- PMM
>
> --
> Alex Bennée
> Virtualisation Tech Lead @ Linaro
>

On Wed, 28 Jan 2026, Alex Bennée wrote:
> Ruslan Ruslichenko <ruslichenko.r@gmail.com> writes:
>> On Tue, Jan 27, 2026 at 11:03 AM Peter Maydell <peter.maydell@linaro.org> wrote:
>>> On Mon, 26 Jan 2026 at 17:43, Ruslan Ruslichenko
>>> <ruslichenko.r@gmail.com> wrote:
>>>>
>>>> From: Ruslan Ruslichenko <Ruslan_Ruslichenko@epam.com>
>>>>
>>>> This patch series introduces new ARM machine model, arm-generic-fdt, and the underlying infrastructure required to instantiate a QEMU machine from a Device Tree.
>>>
>>> I'm afraid this has been a feature that has been suggested from
>>> time to time, but which I don't think is workable in general.
>>>
>>> Device tree files are designed to provide enough information to
>>> the guest kernel to allow it to find non-probeable hardware. They
>>> are not designed to provide enough information to QEMU to allow
>>> it to create and wire up all the hardware present on the system.
>>>
>>> There are specific niches where it can be made to work -- I think
>>> Xilinx have or had a setup where they were generating an FPGA
>>> model and a device tree and a guest kernel all from the same
>>> single data source, so they could put everything necessary into
>>> the dtb, for example -- but I don't think it works in the
>>> general case. As one simple example, the DTB doesn't generally
>>> have any information about how the Secure world works in an Arm
>>> system, because Linux doesn't care about the Secure world. It
>>> also doesn't usually have information that the guest OS can
>>> probe for itself at runtime.
>>>
>>> There has been periodic discussion of more flexible user-driven
>>> board creation, but that has generally been with the idea of using
>>> the QMP monitor to orchestrate creation and connection of device
>>> models.
>>>
>> I agree that a guest Device Tree is insufficient for describing a
>> complete QEMU machine model.
>> However, we separate the guest configuration from the machine
>> definition. The -hw-dtb option allows the user to provide a
>> QEMU-specific system description.
>> Those hw-dtb would not be passed to Linux Guest VM.
>>
>> The fact that this workflow has been successfully used in production
>> by AMD/Xilinx demonstrates that FDT is a feasible format.
>
> Where are the extensions to the FDT used for hw-dtb documented? How does
> it deal with PCI devices and the Secure world?

PCI devices don't need to be included in a machine description as they are 
not part of the machine only the PCI host is. PCI devices are plugged into 
the host with -device as with boards defined in C. For PCI devices that 
are instantiated by default on some machines including a node below the 
PCI host should likely work. I know nothing about secure world, that may 
need some extensions but fdt is basically describing objects and their 
properties so if it's one or a hierarchy of QOM objects that needs to be 
instantiated with defined properties it should be possible to describe it 
in fdt.

>> In contrast, QMP usage may end up even more complex and less
>> maintainable for the task of full system modeling.
>> To my understanding, this would need to generate too long configs,
>> which may eventually require some intermediate format by itself.
>>
>> I am proposing to use FDT as a serialization format to describe a
>> machine configuration. Theoretically we can use other formats, like
>> XML, but in my opinion FDT perfectly matches the requirements.
>
> The QMP interface is self-documenting and introspectable and used for
> the management of QEMU including things like hotplug. It is also QOM
> aware so a natural fit for dealing with the underlying QOM machinery.

QOM seems to be more about operating a machine rather than defining it for 
which fdt is an already established common way.

> Previous discussions have entertained the idea of making the parsing of
> hw-dtb an external script which would then translate into QMP commands
> to build up the machine.

That would be possible but it seems that directly parsing fdt in QEMU 
could be done with very few code and with some additional support from 
devices the latter of which is probably also needed when trying to 
interactively define a machine from command line, monitor or QMP.

Regards,
BALATON Zoltan

BALATON Zoltan <balaton@eik.bme.hu> writes:

> On Wed, 28 Jan 2026, Alex Bennée wrote:
>> Ruslan Ruslichenko <ruslichenko.r@gmail.com> writes:
>>> On Tue, Jan 27, 2026 at 11:03 AM Peter Maydell <peter.maydell@linaro.org> wrote:
>>>> On Mon, 26 Jan 2026 at 17:43, Ruslan Ruslichenko
>>>> <ruslichenko.r@gmail.com> wrote:
>>>>>
>>>>> From: Ruslan Ruslichenko <Ruslan_Ruslichenko@epam.com>
>>>>>
>>>>> This patch series introduces new ARM machine model, arm-generic-fdt, and the underlying infrastructure required to instantiate a QEMU machine from a Device Tree.
>>>>
>>>> I'm afraid this has been a feature that has been suggested from
>>>> time to time, but which I don't think is workable in general.
>>>>
>>>> Device tree files are designed to provide enough information to
>>>> the guest kernel to allow it to find non-probeable hardware. They
>>>> are not designed to provide enough information to QEMU to allow
>>>> it to create and wire up all the hardware present on the system.
>>>>
>>>> There are specific niches where it can be made to work -- I think
>>>> Xilinx have or had a setup where they were generating an FPGA
>>>> model and a device tree and a guest kernel all from the same
>>>> single data source, so they could put everything necessary into
>>>> the dtb, for example -- but I don't think it works in the
>>>> general case. As one simple example, the DTB doesn't generally
>>>> have any information about how the Secure world works in an Arm
>>>> system, because Linux doesn't care about the Secure world. It
>>>> also doesn't usually have information that the guest OS can
>>>> probe for itself at runtime.
>>>>
>>>> There has been periodic discussion of more flexible user-driven
>>>> board creation, but that has generally been with the idea of using
>>>> the QMP monitor to orchestrate creation and connection of device
>>>> models.
>>>>
>>> I agree that a guest Device Tree is insufficient for describing a
>>> complete QEMU machine model.
>>> However, we separate the guest configuration from the machine
>>> definition. The -hw-dtb option allows the user to provide a
>>> QEMU-specific system description.
>>> Those hw-dtb would not be passed to Linux Guest VM.
>>>
>>> The fact that this workflow has been successfully used in production
>>> by AMD/Xilinx demonstrates that FDT is a feasible format.
>>
>> Where are the extensions to the FDT used for hw-dtb documented? How does
>> it deal with PCI devices and the Secure world?
>
> PCI devices don't need to be included in a machine description as they
> are not part of the machine only the PCI host is. PCI devices are
> plugged into the host with -device as with boards defined in C.

But if we are talking about a general purpose HW description DSL then we
do need to describe systems with embedded PCI busses and soldered on PCI
devices.

> For
> PCI devices that are instantiated by default on some machines
> including a node below the PCI host should likely work. I know nothing
> about secure world, that may need some extensions but fdt is basically
> describing objects and their properties so if it's one or a hierarchy
> of QOM objects that needs to be instantiated with defined properties
> it should be possible to describe it in fdt.

OK - hence I was asking for the documentation for how this is done. You
can't just assert that anything can be described in DTB because its
original use case is purely for OS descriptions. If we want to explore
this series further then I would suggest including some hw-dtb's in the
series to replicate some of our more embedded machines in the next
revision.

>>> In contrast, QMP usage may end up even more complex and less
>>> maintainable for the task of full system modeling.
>>> To my understanding, this would need to generate too long configs,
>>> which may eventually require some intermediate format by itself.
>>>
>>> I am proposing to use FDT as a serialization format to describe a
>>> machine configuration. Theoretically we can use other formats, like
>>> XML, but in my opinion FDT perfectly matches the requirements.
>>
>> The QMP interface is self-documenting and introspectable and used for
>> the management of QEMU including things like hotplug. It is also QOM
>> aware so a natural fit for dealing with the underlying QOM machinery.
>
> QOM seems to be more about operating a machine rather than defining it
> for which fdt is an already established common way.
>
>> Previous discussions have entertained the idea of making the parsing of
>> hw-dtb an external script which would then translate into QMP commands
>> to build up the machine.
>
> That would be possible but it seems that directly parsing fdt in QEMU
> could be done with very few code and with some additional support from
> devices the latter of which is probably also needed when trying to
> interactively define a machine from command line, monitor or QMP.

I agree QMP would need some new APIs to support this - and also have
some examples of how to replicate the existing machines over a pure QMP
interface.

>
> Regards,
> BALATON Zoltan

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

On Thu, Jan 29, 2026 at 1:23 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>
> BALATON Zoltan <balaton@eik.bme.hu> writes:
>
> > On Wed, 28 Jan 2026, Alex Bennée wrote:
> >> Ruslan Ruslichenko <ruslichenko.r@gmail.com> writes:
> >>> On Tue, Jan 27, 2026 at 11:03 AM Peter Maydell <peter.maydell@linaro.org> wrote:
> >>>> On Mon, 26 Jan 2026 at 17:43, Ruslan Ruslichenko
> >>>> <ruslichenko.r@gmail.com> wrote:
> >>>>>
> >>>>> From: Ruslan Ruslichenko <Ruslan_Ruslichenko@epam.com>
> >>>>>
> >>>>> This patch series introduces new ARM machine model, arm-generic-fdt, and the underlying infrastructure required to instantiate a QEMU machine from a Device Tree.
> >>>>
> >>>> I'm afraid this has been a feature that has been suggested from
> >>>> time to time, but which I don't think is workable in general.
> >>>>
> >>>> Device tree files are designed to provide enough information to
> >>>> the guest kernel to allow it to find non-probeable hardware. They
> >>>> are not designed to provide enough information to QEMU to allow
> >>>> it to create and wire up all the hardware present on the system.
> >>>>
> >>>> There are specific niches where it can be made to work -- I think
> >>>> Xilinx have or had a setup where they were generating an FPGA
> >>>> model and a device tree and a guest kernel all from the same
> >>>> single data source, so they could put everything necessary into
> >>>> the dtb, for example -- but I don't think it works in the
> >>>> general case. As one simple example, the DTB doesn't generally
> >>>> have any information about how the Secure world works in an Arm
> >>>> system, because Linux doesn't care about the Secure world. It
> >>>> also doesn't usually have information that the guest OS can
> >>>> probe for itself at runtime.
> >>>>
> >>>> There has been periodic discussion of more flexible user-driven
> >>>> board creation, but that has generally been with the idea of using
> >>>> the QMP monitor to orchestrate creation and connection of device
> >>>> models.
> >>>>
> >>> I agree that a guest Device Tree is insufficient for describing a
> >>> complete QEMU machine model.
> >>> However, we separate the guest configuration from the machine
> >>> definition. The -hw-dtb option allows the user to provide a
> >>> QEMU-specific system description.
> >>> Those hw-dtb would not be passed to Linux Guest VM.
> >>>
> >>> The fact that this workflow has been successfully used in production
> >>> by AMD/Xilinx demonstrates that FDT is a feasible format.
> >>
> >> Where are the extensions to the FDT used for hw-dtb documented? How does
> >> it deal with PCI devices and the Secure world?
> >
> > PCI devices don't need to be included in a machine description as they
> > are not part of the machine only the PCI host is. PCI devices are
> > plugged into the host with -device as with boards defined in C.
>
> But if we are talking about a general purpose HW description DSL then we
> do need to describe systems with embedded PCI busses and soldered on PCI
> devices.
>
> > For
> > PCI devices that are instantiated by default on some machines
> > including a node below the PCI host should likely work. I know nothing
> > about secure world, that may need some extensions but fdt is basically
> > describing objects and their properties so if it's one or a hierarchy
> > of QOM objects that needs to be instantiated with defined properties
> > it should be possible to describe it in fdt.
>
> OK - hence I was asking for the documentation for how this is done. You
> can't just assert that anything can be described in DTB because its
> original use case is purely for OS descriptions. If we want to explore
> this series further then I would suggest including some hw-dtb's in the
> series to replicate some of our more embedded machines in the next
> revision.
>

Sure, we can consider more functional examples for the v2 patch series.
Would you like to see some specific machine constructed with hw-dtb?

Also answering the previous question regarding Secure world.
We can define parent nodes in the FDT that represent Memory Region
containers, which are then mapped into the CPU's Secure Address Space.

Any child devices defined under these nodes in the FDT are automatically
instantiated as subregions of that parent container. This ensures they
are only visible to the Secure World.

> >>> In contrast, QMP usage may end up even more complex and less
> >>> maintainable for the task of full system modeling.
> >>> To my understanding, this would need to generate too long configs,
> >>> which may eventually require some intermediate format by itself.
> >>>
> >>> I am proposing to use FDT as a serialization format to describe a
> >>> machine configuration. Theoretically we can use other formats, like
> >>> XML, but in my opinion FDT perfectly matches the requirements.
> >>
> >> The QMP interface is self-documenting and introspectable and used for
> >> the management of QEMU including things like hotplug. It is also QOM
> >> aware so a natural fit for dealing with the underlying QOM machinery.
> >
> > QOM seems to be more about operating a machine rather than defining it
> > for which fdt is an already established common way.
> >
> >> Previous discussions have entertained the idea of making the parsing of
> >> hw-dtb an external script which would then translate into QMP commands
> >> to build up the machine.
> >
> > That would be possible but it seems that directly parsing fdt in QEMU
> > could be done with very few code and with some additional support from
> > devices the latter of which is probably also needed when trying to
> > interactively define a machine from command line, monitor or QMP.
>
> I agree QMP would need some new APIs to support this - and also have
> some examples of how to replicate the existing machines over a pure QMP
> interface.
>
> >
> > Regards,
> > BALATON Zoltan
>
> --
> Alex Bennée
> Virtualisation Tech Lead @ Linaro

Ruslan Ruslichenko <ruslichenko.r@gmail.com> writes:

> On Thu, Jan 29, 2026 at 1:23 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>> BALATON Zoltan <balaton@eik.bme.hu> writes:
>>
>> > On Wed, 28 Jan 2026, Alex Bennée wrote:
>> >> Ruslan Ruslichenko <ruslichenko.r@gmail.com> writes:
>> >>> On Tue, Jan 27, 2026 at 11:03 AM Peter Maydell <peter.maydell@linaro.org> wrote:
>> >>>> On Mon, 26 Jan 2026 at 17:43, Ruslan Ruslichenko
>> >>>> <ruslichenko.r@gmail.com> wrote:
>> >>>>>
>> >>>>> From: Ruslan Ruslichenko <Ruslan_Ruslichenko@epam.com>
>> >>>>>
>> >>>>> This patch series introduces new ARM machine model, arm-generic-fdt, and the underlying infrastructure required to instantiate a QEMU machine from a Device Tree.
>> >>>>
>> >>>> I'm afraid this has been a feature that has been suggested from
>> >>>> time to time, but which I don't think is workable in general.
>> >>>>
>> >>>> Device tree files are designed to provide enough information to
>> >>>> the guest kernel to allow it to find non-probeable hardware. They
>> >>>> are not designed to provide enough information to QEMU to allow
>> >>>> it to create and wire up all the hardware present on the system.
>> >>>>
>> >>>> There are specific niches where it can be made to work -- I think
>> >>>> Xilinx have or had a setup where they were generating an FPGA
>> >>>> model and a device tree and a guest kernel all from the same
>> >>>> single data source, so they could put everything necessary into
>> >>>> the dtb, for example -- but I don't think it works in the
>> >>>> general case. As one simple example, the DTB doesn't generally
>> >>>> have any information about how the Secure world works in an Arm
>> >>>> system, because Linux doesn't care about the Secure world. It
>> >>>> also doesn't usually have information that the guest OS can
>> >>>> probe for itself at runtime.
>> >>>>
>> >>>> There has been periodic discussion of more flexible user-driven
>> >>>> board creation, but that has generally been with the idea of using
>> >>>> the QMP monitor to orchestrate creation and connection of device
>> >>>> models.
>> >>>>
>> >>> I agree that a guest Device Tree is insufficient for describing a
>> >>> complete QEMU machine model.
>> >>> However, we separate the guest configuration from the machine
>> >>> definition. The -hw-dtb option allows the user to provide a
>> >>> QEMU-specific system description.
>> >>> Those hw-dtb would not be passed to Linux Guest VM.
>> >>>
>> >>> The fact that this workflow has been successfully used in production
>> >>> by AMD/Xilinx demonstrates that FDT is a feasible format.
>> >>
>> >> Where are the extensions to the FDT used for hw-dtb documented? How does
>> >> it deal with PCI devices and the Secure world?
>> >
>> > PCI devices don't need to be included in a machine description as they
>> > are not part of the machine only the PCI host is. PCI devices are
>> > plugged into the host with -device as with boards defined in C.
>>
>> But if we are talking about a general purpose HW description DSL then we
>> do need to describe systems with embedded PCI busses and soldered on PCI
>> devices.
>>
>> > For
>> > PCI devices that are instantiated by default on some machines
>> > including a node below the PCI host should likely work. I know nothing
>> > about secure world, that may need some extensions but fdt is basically
>> > describing objects and their properties so if it's one or a hierarchy
>> > of QOM objects that needs to be instantiated with defined properties
>> > it should be possible to describe it in fdt.
>>
>> OK - hence I was asking for the documentation for how this is done. You
>> can't just assert that anything can be described in DTB because its
>> original use case is purely for OS descriptions. If we want to explore
>> this series further then I would suggest including some hw-dtb's in the
>> series to replicate some of our more embedded machines in the next
>> revision.
>>
>
> Sure, we can consider more functional examples for the v2 patch series.
> Would you like to see some specific machine constructed with hw-dtb?
>
> Also answering the previous question regarding Secure world.
> We can define parent nodes in the FDT that represent Memory Region
> containers, which are then mapped into the CPU's Secure Address Space.
>
> Any child devices defined under these nodes in the FDT are automatically
> instantiated as subregions of that parent container. This ensures they
> are only visible to the Secure World.

I would suggest we pick a representative sample of non-virt machine
types to model in hw-dtb and extend the functional tests to run both. We
have these tests (trimmed of virt, pc, and q35 machines):

  riscv64/test_boston.py:36:        self.set_machine('boston-aia')
  riscv64/test_sifive_u.py:30:        self.set_machine('sifive_u')
  riscv64/test_migration.py:17:        self.set_machine('spike')
  riscv64/test_opensbi.py:24:        self.set_machine('spike')
  riscv64/test_opensbi.py:28:        self.set_machine('sifive_u')
  sparc64/test_tuxrun.py:27:        self.set_machine('sun4u')
  sparc64/test_sun4u.py:28:        self.set_machine('sun4u')
  sparc64/test_migration.py:13:        self.set_machine('sun4u')
  sparc64/test_migration.py:17:        self.set_machine('sun4u')
  sparc64/test_migration.py:21:        self.set_machine('sun4u')
  mipsel/test_malta.py:41:        self.set_machine('malta')
  mipsel/test_malta.py:97:        self.set_machine('malta')
  ppc/test_74xx.py:19:        self.set_machine('g3beige')
  ppc/test_74xx.py:28:        self.set_machine('g3beige')
  ppc/test_74xx.py:37:        self.set_machine('g3beige')
  ppc/test_74xx.py:46:        self.set_machine('g3beige')
  ppc/test_74xx.py:55:        self.set_machine('g3beige')
  ppc/test_74xx.py:64:        self.set_machine('g3beige')
  ppc/test_74xx.py:73:        self.set_machine('g3beige')
  ppc/test_74xx.py:82:        self.set_machine('g3beige')
  ppc/test_74xx.py:91:        self.set_machine('g3beige')
  ppc/test_74xx.py:100:        self.set_machine('g3beige')
  ppc/test_74xx.py:109:        self.set_machine('g3beige')
  ppc/test_74xx.py:118:        self.set_machine('g3beige')
  mips64el/test_malta.py:46:        self.set_machine('malta')
  mips64el/test_malta.py:72:        self.set_machine('malta')
  mips64el/test_malta.py:145:        self.set_machine('malta')
  ppc/test_tuxrun.py:27:        self.set_machine('ppce500')
  mipsel/test_tuxrun.py:27:        self.set_machine('malta')
  ppc/test_bamboo.py:29:        self.set_machine('bamboo')
  sparc/test_sun4m.py:18:        self.set_machine('SS-20')
  ppc/test_replay.py:25:        self.set_machine('g3beige')
  ppc/test_replay.py:29:        self.set_machine('mac99')
  mipsel/test_replay.py:30:        self.set_machine('malta')
  sparc/test_replay.py:19:        self.set_machine('SS-10')
  mips64el/test_tuxrun.py:27:        self.set_machine('malta')
  mips64/test_tuxrun.py:27:        self.set_machine('malta')
  ppc/test_40p.py:40:        self.set_machine('40p')
  ppc/test_40p.py:55:        self.set_machine('40p')
  ppc/test_40p.py:66:        self.set_machine('40p')
  ppc/test_40p.py:81:        self.set_machine('40p')
  sparc/test_migration.py:13:        self.set_machine('SS-4')
  sparc/test_migration.py:17:        self.set_machine('SS-5')
  sparc/test_migration.py:21:        self.set_machine('SS-4')
  mips64el/test_replay.py:22:        self.set_machine('malta')
  mips64el/test_replay.py:45:        self.set_machine('malta')
  ppc/test_amiga.py:25:        self.set_machine('amigaone')
  avr/test_uno.py:21:        self.set_machine('arduino-uno')
  ppc/test_ppe42.py:68:        self.set_machine('ppe42_machine')
  avr/test_mega2560.py:38:        self.set_machine('arduino-mega-2560-v3')
  mips64el/test_fuloong2e.py:33:        self.set_machine('fuloong2e')
  mips64el/test_fuloong2e.py:54:        self.set_machine('fuloong2e')
  ppc/test_migration.py:13:        self.set_machine('sam460ex')
  ppc/test_migration.py:17:        self.set_machine('sam460ex')
  ppc/test_migration.py:21:        self.set_machine('sam460ex')
  ppc/test_mpc8544ds.py:27:        self.set_machine('mpc8544ds')
  ppc/test_sam460ex.py:19:        self.set_machine('sam460ex')
  ppc/test_mac.py:28:        self.set_machine('g3beige')
  ppc/test_mac.py:32:        self.set_machine('mac99')
  ppc/test_virtex_ml507.py:27:        self.set_machine('virtex-ml507')
  riscv32/test_migration.py:13:        self.set_machine('spike')
  riscv32/test_migration.py:21:        self.set_machine('spike')
  mips/test_malta.py:57:    test.set_machine('malta')
  mips/test_malta.py:108:        self.set_machine('malta')
  mips/test_malta.py:131:        self.set_machine('malta')
  sh4eb/test_r2d.py:18:        self.set_machine('r2d')
  or1k/test_sim.py:18:        self.set_machine('or1k-sim')
  alpha/test_replay.py:20:        self.set_machine('clipper')
  mips/test_tuxrun.py:27:        self.set_machine('malta')
  or1k/test_replay.py:19:        self.set_machine('or1k-sim')
  alpha/test_clipper.py:19:        self.set_machine('clipper')
  mips/test_replay.py:22:        self.set_machine('malta')
  mips/test_replay.py:43:        self.set_machine('malta')
  arm/test_tuxrun.py:30:        self.set_machine('versatilepb')
  alpha/test_migration.py:13:        self.set_machine('clipper')
  alpha/test_migration.py:17:        self.set_machine('clipper')
  alpha/test_migration.py:21:        self.set_machine('clipper')
  m68k/test_mcf5208evb.py:18:        self.set_machine('mcf5208evb')
  m68k/test_replay.py:21:        self.set_machine('q800')
  m68k/test_replay.py:35:        self.set_machine('mcf5208evb')
  arm/test_bpim2u.py:40:        self.set_machine('bpim2u')
  arm/test_bpim2u.py:61:        self.set_machine('bpim2u')
  arm/test_bpim2u.py:94:        self.set_machine('bpim2u')
  arm/test_bpim2u.py:142:        self.set_machine('bpim2u')
  rx/test_gdbsim.py:37:        self.set_machine('gdbsim-r5f562n8')
  rx/test_gdbsim.py:57:        self.set_machine('gdbsim-r5f562n7')
  m68k/test_nextcube.py:49:        self.set_machine('next-cube')
  m68k/test_nextcube.py:61:        self.set_machine('next-cube')
  s390x/test_reverse_debug.py:15:        self.set_machine('s390-ccw-virtio')
  arm/test_integratorcp.py:45:        self.set_machine('integratorcp')
  hppa/test_cdboot.py:19:        self.set_machine('B160L')
  m68k/test_q800.py:19:        self.set_machine('q800')
  hppa/test_seabios.py:27:        self.set_machine('B160L')
  hppa/test_seabios.py:31:        self.set_machine('C3700')
  arm/test_cubieboard.py:38:        self.set_machine('cubieboard')
  arm/test_cubieboard.py:69:        self.set_machine('cubieboard')
  arm/test_cubieboard.py:107:        self.set_machine('cubieboard')
  arm/test_realview.py:21:        self.set_machine('realview-eb-mpcore')
  s390x/test_pxelinux.py:56:        self.set_machine('s390-ccw-virtio')
  arm/test_sx1.py:40:        self.set_machine('sx1')
  arm/test_sx1.py:51:        self.set_machine('sx1')
  arm/test_sx1.py:62:        self.set_machine('sx1')
  arm/test_replay.py:38:        self.set_machine('cubieboard')
  arm/test_replay.py:60:        self.set_machine('vexpress-a9')
  arm/test_aspeed_ast2600_buildroot.py:25:        self.set_machine('ast2600-evb')
  arm/test_aspeed_ast2600_buildroot.py:99:        self.set_machine('ast2600-evb')
  arm/test_canona1100.py:27:        self.set_machine('canon-a1100')
  sh4/test_r2d.py:21:        self.set_machine('r2d')
  xtensa/test_replay.py:19:        self.set_machine('lx60')
  arm/test_max78000fthr.py:19:        self.set_machine('max78000fthr')
  arm/test_raspi2.py:42:        self.set_machine('raspi2b')
  arm/test_raspi2.py:68:        self.set_machine('raspi2b')
  microblaze/test_replay.py:20:        self.set_machine('petalogix-s3adsp1800')
  sh4/test_tuxrun.py:27:        self.set_machine('r2d')
  xtensa/test_lx60.py:18:        self.set_machine('lx60')
  arm/test_smdkc210.py:24:        self.set_machine('smdkc210')
  arm/test_microbit.py:19:        self.set_machine('microbit')
  arm/test_collie.py:22:        self.set_machine('collie')
  arm/test_quanta_gsj.py:35:        self.set_machine('quanta-gsj')
  arm/test_quanta_gsj.py:71:        self.set_machine('quanta-gsj')
  arm/test_vexpress.py:18:        self.set_machine('vexpress-a9')
  microblaze/test_s3adsp1800.py:29:        self.set_machine('petalogix-s3adsp1800')
  microblaze/test_s3adsp1800.py:46:        self.set_machine('petalogix-s3adsp1800')
  arm/test_emcraft_sf2.py:26:        self.set_machine('emcraft-sf2')
  arm/test_aspeed_ast1060.py:21:        self.set_machine('ast1060-evb')
  arm/test_aspeed_ast1060.py:35:        self.vm.set_machine("ast1060-evb")
  arm/test_aspeed_rainier.py:16:        self.set_machine('rainier-bmc')
  arm/test_aspeed_rainier.py:42:        self.set_machine('rainier-bmc')
  arm/test_aspeed_ast1030.py:21:        self.set_machine('ast1030-evb')
  arm/test_aspeed_ast1030.py:40:        self.set_machine('ast1030-evb')
  arm/test_aspeed_ast1030.py:72:        self.vm.set_machine("ast1030-evb")
  arm/test_aspeed_ast2600_sdk.py:35:        self.set_machine('ast2600-evb')
  arm/test_aspeed_ast2600_sdk.py:74:        self.vm.set_machine("ast2600-evb")
  arm/test_stellaris.py:18:        self.set_machine('lm3s6965evb')
  arm/test_stellaris.py:32:        self.set_machine('lm3s811evb')
  arm/test_migration.py:13:        self.set_machine('npcm750-evb')
  arm/test_migration.py:17:        self.set_machine('npcm750-evb')
  arm/test_migration.py:21:        self.set_machine('npcm750-evb')
  arm/test_aspeed_ast2500.py:19:        self.set_machine('ast2500-evb')
  arm/test_aspeed_ast2500.py:45:        self.set_machine('ast2500-evb')
  aarch64/test_raspi4.py:37:        self.set_machine('raspi4b')
  aarch64/test_raspi4.py:67:        self.set_machine('raspi4b')
  arm/test_orangepi.py:51:        self.set_machine('orangepi-pc')
  arm/test_orangepi.py:72:        self.set_machine('orangepi-pc')
  arm/test_orangepi.py:105:        self.set_machine('orangepi-pc')
  arm/test_orangepi.py:149:        self.set_machine('orangepi-pc')
  arm/test_orangepi.py:185:        self.set_machine('orangepi-pc')
  ppc64/test_reverse_debug.py:25:        self.set_machine('pseries')
  ppc64/test_reverse_debug.py:33:        self.set_machine('powernv')
  aarch64/test_imx8mp_evk.py:53:        self.set_machine('imx8mp-evk')
  ppc64/test_migration.py:14:        self.set_machine('mac99')
  ppc64/test_migration.py:18:        self.set_machine('mac99')
  ppc64/test_migration.py:22:        self.set_machine('mac99')
  ppc64/test_e500.py:22:        self.set_machine('ppce500')
  aarch64/test_raspi3.py:24:        self.set_machine('raspi3b')
  ppc64/test_mac99.py:23:        self.set_machine('mac99')
  ppc64/test_replay.py:21:        self.set_machine('ppce500')
  ppc64/test_replay.py:34:        self.set_machine('pseries')
  aarch64/test_aspeed_ast2700.py:151:        self.set_machine('ast2700a1-evb')
  aarch64/test_aspeed_ast2700.py:163:        self.set_machine('ast2700a1-evb')
  aarch64/test_aspeed_ast2700.py:174:        self.set_machine('ast2700a1-evb')
  aarch64/test_aspeed_ast2700.py:178:        self.vm.set_machine('ast2700a1-evb,fmc-model=w25q512jv')
  aarch64/test_migration.py:13:        self.set_machine('quanta-gsj')
  aarch64/test_migration.py:17:        self.set_machine('quanta-gsj')
  aarch64/test_migration.py:21:        self.set_machine('quanta-gsj')
  aarch64/test_aspeed_ast2700fc.py:152:        self.set_machine('ast2700fc')
  aarch64/test_aspeed_ast2700fc.py:164:        self.set_machine('ast2700fc')


Thinking about it Arm's sbsa-ref would be an interesting one to check
for fidelity as the firmware stack targets an explicit HW platform.

>
>> >>> In contrast, QMP usage may end up even more complex and less
>> >>> maintainable for the task of full system modeling.
>> >>> To my understanding, this would need to generate too long configs,
>> >>> which may eventually require some intermediate format by itself.
>> >>>
>> >>> I am proposing to use FDT as a serialization format to describe a
>> >>> machine configuration. Theoretically we can use other formats, like
>> >>> XML, but in my opinion FDT perfectly matches the requirements.
>> >>
>> >> The QMP interface is self-documenting and introspectable and used for
>> >> the management of QEMU including things like hotplug. It is also QOM
>> >> aware so a natural fit for dealing with the underlying QOM machinery.
>> >
>> > QOM seems to be more about operating a machine rather than defining it
>> > for which fdt is an already established common way.
>> >
>> >> Previous discussions have entertained the idea of making the parsing of
>> >> hw-dtb an external script which would then translate into QMP commands
>> >> to build up the machine.
>> >
>> > That would be possible but it seems that directly parsing fdt in QEMU
>> > could be done with very few code and with some additional support from
>> > devices the latter of which is probably also needed when trying to
>> > interactively define a machine from command line, monitor or QMP.
>>
>> I agree QMP would need some new APIs to support this - and also have
>> some examples of how to replicate the existing machines over a pure QMP
>> interface.
>>
>> >
>> > Regards,
>> > BALATON Zoltan
>>
>> --
>> Alex Bennée
>> Virtualisation Tech Lead @ Linaro

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

On Tue, 27 Jan 2026, Peter Maydell wrote:
> On Mon, 26 Jan 2026 at 17:43, Ruslan Ruslichenko
> <ruslichenko.r@gmail.com> wrote:
>>
>> From: Ruslan Ruslichenko <Ruslan_Ruslichenko@epam.com>
>>
>> This patch series introduces new ARM machine model, arm-generic-fdt, and the underlying infrastructure required to instantiate a QEMU machine from a Device Tree.
>
> I'm afraid this has been a feature that has been suggested from
> time to time, but which I don't think is workable in general.

There were another experiment by Bernhard Beschow here: 
<https://github.com/shentok/qemu/commits/e500-fdt/> which seems 
surprisingly simple (the actual change to allow fdt based creation is 
this: 
<https://github.com/shentok/qemu/commit/857b19fe4bbb0ec42c92dab48411b5b8ab2da02c>) 
and works for creating some PPC e500 based machines (still work in 
progress though). We had a discussion of this here: 
<https://lists.nongnu.org/archive/html/qemu-ppc/2025-02/msg00198.html>
I don't remember if an RFC was submitted later and there were more reviews 
on that.

> Device tree files are designed to provide enough information to
> the guest kernel to allow it to find non-probeable hardware. They
> are not designed to provide enough information to QEMU to allow
> it to create and wire up all the hardware present on the system.
>
> There are specific niches where it can be made to work -- I think
> Xilinx have or had a setup where they were generating an FPGA
> model and a device tree and a guest kernel all from the same
> single data source, so they could put everything necessary into
> the dtb, for example -- but I don't think it works in the
> general case. As one simple example, the DTB doesn't generally
> have any information about how the Secure world works in an Arm
> system, because Linux doesn't care about the Secure world. It
> also doesn't usually have information that the guest OS can
> probe for itself at runtime.
>
> There has been periodic discussion of more flexible user-driven
> board creation, but that has generally been with the idea of using
> the QMP monitor to orchestrate creation and connection of device
> models.

Whatever interface is used to instantiate the objects it would need some 
description language to describe the machine and FDT while not the most 
user friendly can do that so it can be a candidate or alternative for 
other description language which can be considered. If the fdt that comes 
with Linux does not contain everything QEMU could still use a modified 
enhanced fdt that adds the needed details as long as fdt itself can 
describe that. It's nice if QEMU does not have to supply it's own FDT 
files and can just use those from Linux but even if that would not work 
does not mean fdt is not a usable way to define a machine.

Regards,
BALATON Zoltan