On Wed, 25 Feb 2026 at 01:05, BALATON Zoltan <[email protected]> wrote: > > On Tue, 24 Feb 2026, Mark Cave-Ayland wrote: > > The questions I think we need to answer as a starting point: > > > > 1. Which API shall we converge on: qdev or QOM? Can we come up with a > > code sample(s) showing what we want object/device initialisation to > > look lie? Longer term can we unify the QOM and qdev trees? > > My first question is why do we have separate qom and qdev names and trees? > The docs aren't very helpful. Qdev does not have a Glossary entry and only > a brief summary at: > https://www.qemu.org/docs/master/devel/qdev-api.html > and some confusing info in an old doc here > https://habkost.net/posts/2016/11/incomplete-list-of-qemu-apis.html > > For a long time I did not even know there was info qom-tree command in > monitor but I was familiar with and used info qtree. I still don't know > what the qom-tree is good for therefore I also don't care when creating > machines or devices as I never use it and don't know why I would want to > use it. To me it looks like some internal thing of QEMU that I don't have > to be concerned with. All the useful info about devices are in info qtree.
The qdev tree is the older of the two. It models the buses: devices can own buses, and devices are (mostly) on buses. The classic example is something like PCI: the PCI controller device owns a PCI bus, and various PCI network devices etc are children of that bus. Reset is (currently) done by traversing the this tree. The qdev tree represents a real thing in the hardware we're modelling. (The "sysbus" is an odd thing that has all the memory-mapped devices on it, which is kind of broken in that a memory-mapped subcomponent of a PCI device is still on the "sysbus". There are also problems with devices that aren't on buses at all, notably the CPUs: they don't get reset automatically, for instance.) The QOM tree is newer, and was introduced when QOM was. It is a tree of ownership of objects: the machine owns all the devices it creates, including perhaps an SoC object; the SoC object owns all the devices that are its subparts (the UART, the I2C controller, etc), and so on. It provides a hierarchy that the qdev/qbus one cannot, because not all "this object owns this other object" relations are ones where the other object is on a bus owned by this one. Conversely, not all "device A is on a bus owned by device B" relations are "device B owns device A" ones -- consider an SoC with a PCI controller and a PCI device that's created via the command line: the PCI controller doesn't own that PCI device. In that "PCI device with a memory mapped subcomponent" example above, the memory-mapped subcomponent is a child of the PCI device in the QOM tree, so here QOM gets something right that the qbus tree doesn't. -- PMM
