On Tue, 27 Jan 2026, Peter Maydell 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.
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
