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? > 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
