On Wed, 28 Jan 2026, Alex Bennée wrote:
Ruslan Ruslichenko <[email protected]> writes:
On Tue, Jan 27, 2026 at 11:03 AM Peter Maydell <[email protected]> wrote:
On Mon, 26 Jan 2026 at 17:43, Ruslan Ruslichenko
<[email protected]> wrote:
From: Ruslan Ruslichenko <[email protected]>
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
