On Thu, 26 Feb 2026, Peter Maydell wrote:
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.
This probably answers the question of this patch if we should decide the
qom-tree path based on bus and the answer seems to be no as these are
different things. But then what is this ownership tree used for? Maybe it
should be more clearly defined what this ownership relation means and why
do we want to keep track of it. It looks like it works with most devices
being unattached so this is just some info we don't really need. In that
case why do we want to make effort setting it?
Regards,
BALATON Zoltan
