On Wed, Jan 28, 2026 at 11:48 AM Alex Bennée <[email protected]> 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? > > 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 >
