Am 26. Februar 2026 11:58:34 UTC schrieb Peter Maydell <[email protected]>: >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. Yeah, QOM, among other things, seems to be the infrastructure for intrusive, ref-countes smart pointers. Unlike Rust or C++, C doesn't have a concept of destructors which are invoked implicitly and recursively when an object goes out of scope. So we need to maintain a tree that allows us to run destructors like that -- the QOM tree. Ideally, we'd destruct the whole tree when the QEMU process finishes. However, this is marked as todo since years: <https://gitlab.com/qemu-project/qemu/-/blob/v10.2.1/system/runstate.c#L1002> . So it seems that we're basically leaking the whole machine and don't clean up properly. Attempting to fix this first reveals that the machine object's refcount is 2, because apparently an object_unref() is required after setting its parent. After having fixed that as well, one can witness QEMU crashing in various interesting ways when quitting. Fixing the unwinding of the QOM tree may perhaps shed some light on what we need and what we want... Clearly a rabbit hole. Best regards, Bernhard > >-- PMM >
