Re: QOM parent type "sys-bus-device" vs. "device"
Peter Maydell writes: > On Thu, 5 Mar 2026 at 09:25, Markus Armbruster wrote: >> > Disentangling reset is extremely painful -- I don't even know >> > what it ought to be doing. Maybe propagating along the QOM tree? >> >> I think this would make more sense. Unlike the qtree, the QOM >> composition tree contains all devices, and reflects the actual >> composition. It's certainly closer to the real reset tree than the >> qtree is. Is it close enough? I don't know. If yes, there's our reset >> tree. If no, I guess we could still use it as a base, with manually >> corrected reset lines where the QOM composition tree is off. A walk to the farmers market jogged my memory: the QOM composition tree is in fact off for user-created devices. These go into /machine/peripheral and /machine/peripheral-anon. Most of them plug into a bus, and reset should flow through that bus, not through their peripheral container. A few don't, and I can't say how reset is supposed to work then. Onboard device can also be connected via some bus. For instance, machine "pc" contains sysbus device "i440FX-pcihost", which provides a PCI bus. It also contains PCI device "PIIX3" (the south bridge) connected via that PCI bus. The QOM composition tree has "i440FX-pcihost" and its PCI bus in the right place, and "PIIX3" in the orphanage: /machine (pc-i440fx-11.0-machine) /i440fx (i440FX-pcihost) /pci.0 (PCI) /unattached (container) /device[3] (PIIX3) /sysbus (System) Say we fixed that like so /machine (pc-i440fx-11.0-machine) /i440fx (i440FX-pcihost) /pci.0 (PCI) /piix3 (PIIX3) then reset flowing along the composition tree is still problematic: we probably want to reset the PCI bus before the devices plugged into it. So maybe reset should flow along the composition tree to buses, from bus to devices plugged into it, from such a device again along the composition tree, and so forth. > Yes. We really don't want to add more boilerplate requirements > to how you write "container" type devices like SoC objects. > It's already bad enough that you have to have an instance_init > that manually calls instance_init on all your subcomponents, > and a realize that calls realize on all of them. If we add > a requirement that you need to have reset methods for 3 phases > that call reset on all your subcomponents, people are going to > forget. We need the default to be "do the thing that's right > almost every time", not "do the thing that's wrong". Good interfaces make doing the right thing easier than doing the wrong thing. We clearly failed there. > (And then of course there is the "how do we get there from > here?" question :-)) Good question. Next question? SCNR! I'm afraid I don't understand how reset works *now* well enough to come up with a workable plan. In other words, I don't have a clear idea of "here", and I fear we together don't have a sufficiently clear idea of "there". What can we do to improve on both?
Re: QOM parent type "sys-bus-device" vs. "device"
On Thu, 5 Mar 2026 at 09:25, Markus Armbruster wrote: > > Disentangling reset is extremely painful -- I don't even know > > what it ought to be doing. Maybe propagating along the QOM tree? > > I think this would make more sense. Unlike the qtree, the QOM > composition tree contains all devices, and reflects the actual > composition. It's certainly closer to the real reset tree than the > qtree is. Is it close enough? I don't know. If yes, there's our reset > tree. If no, I guess we could still use it as a base, with manually > corrected reset lines where the QOM composition tree is off. Yes. We really don't want to add more boilerplate requirements to how you write "container" type devices like SoC objects. It's already bad enough that you have to have an instance_init that manually calls instance_init on all your subcomponents, and a realize that calls realize on all of them. If we add a requirement that you need to have reset methods for 3 phases that call reset on all your subcomponents, people are going to forget. We need the default to be "do the thing that's right almost every time", not "do the thing that's wrong". (And then of course there is the "how do we get there from here?" question :-)) thanks -- PMM
Re: QOM parent type "sys-bus-device" vs. "device"
Peter Maydell writes:
> On Wed, 4 Mar 2026 at 12:25, Markus Armbruster wrote:
>> We might be at a crossroads here.
>>
>> Paul Brook designed qdev around "a device plugs into some bus, and may
>> provide buses". To make this work, he added a main system bus to serve
>> as root of a single tree.
>>
>> The parent of a device in that tree is the bus it plugs into, and the
>> parent of a bus is the device that provides it, except for the main
>> system bus, which has no parent. "info qtree" shows this tree.
>>
>> Note a machine had just this one system bus back then.
>>
>> The system bus isn't something hardware people would call a bus.
>>
>> The qtree is a qdev thing. It is *not* the QOM composition tree ("info
>> qom-tree /").
>>
>> We actually abandoned "a device plugs into some bus" a long time ago.
>> Moe on that below.
>>
>> Qdev was later rebased onto QOM, as follows.
>>
>> A bus QOM type is a subtype of "bus".
>>
>> A device QOM type is a subtype of "device".
>>
>> If a device type has a @bus_type, then it plugs into a bus of that QOM
>> type. Such a concrete device is commonly[*] not a direct subtype of
>> "device". Instead, it's a subtype of the abstract device that plugs
>> into that bus type. Example: "isa-serial" is a direct subtype of
>> "isa-device", and it inherits its bus type "ISA" from there.
>>
>> If a device has no @bus_type, it doesn't plug into any bus. It doesn't
>> show up in "info qtree" (it does in "info qom-tree", of course).
>> Example: "serial" is a direct subtype of "device".
>>
>> This lets us build devices from components without having to make up
>> buses to connect them. Example: "isa-serial" has a direct QOM child of
>> type "serial". Good!
>>
>> Except infrastructure useful to such bus-less devices lives in sysbus,
>> where bus-less devices can't access it. This tempts us to make devices
>> sysbus devices just to be able to use the infrastructure, and to create
>> additional sysbuses.
>
> There is only one sysbus -- it is impossible to create more than one,
> and there wouldn't be much point in creating a second one anyway.
I was almost entirely mistaken there. However, you're not quite right,
either :)
We *can* create more than one system bus, and we in fact do: abstract
PCI device "macio" contains a "macio-bus", which is a subtype of the
system bus type. Its concrete subtypes are "macio-oldworld" and
"macio-newworld". To see the "macio-bus" in "info qtree", try machine
"g3beige".
But this is the rare exception. The rule is us doing something
differently undesirable.
Consider ARM machine "ast2700fc". Its core are three devices:
"ast2700-a2", "aspeed27x0ssp-coprocessor", and
"aspeed27x0tsp-coprocessor". All three contain component devices. The
QOM composition tree shows them as "/machine/ca35", "/machine/ssp", and
"/machine/tsp", i.e. they are direct children of the machine object.
Here's a closer look at a small part of the composition tree:
/machine (ast2700fc-machine)
[...]
/ca35 (ast2700-a2)
[...]
/ioexp[0] (aspeed.ast1700)
[...]
/uart (serial-mm)
/serial (serial)
/serial[0] (memory-region)
I'll refer back to this later.
A few components end up in the "/machine/unattached" orphanage instead
due to sloppy modelling.
My point is: the QOM composition tree actually reflects how devices are
built from components, except for the parts where we got sloppy, which
should be fixable.
The qtree (the thing shown by "info qtree") shows a different picture.
The three core devices are bus-less, and therefore not in the qtree.
Their components, however, are mostly sysbus devices, and therefore in
the qtree right under the root. Here are the parts of the qtree that
correspond to the QOM composition tree snippet above:
bus: main-system-bus
type System
[...]
dev: serial-mm, id ""
gpio-out "sysbus-irq" 1
regshift = 2 (0x2)
endianness = 2 (0x2)
mmio /0020
dev: aspeed.ast1700, id ""
board-idx = 0 (0x0)
silicon-rev = 100794627 (0x6020103)
dram = "/machine/ca35/ca35-dram[0]"
mmio 3000/0100
The "aspeed.ast1700" and its "serial-mm" component are siblings. The
latter's "serial" component is bus-less, and therefore not in the qtree.
Bernhard's patches make it a sysbus device instead, and therefore add it
to the qtree as another sibling.
My point is: the qtree does not reflect how devices are built from
components / are wired together, at least not where sysbus devices are
involved.
>> We can elect to go down this path further: make more sysbus devices.
>> Create more sysbuses. If this is the right path, then bus-less devices
>> were a mistake, and we should consider eliminating them.
>>
>> Or we can pick the other branch: put the infrastructure where bus-less
>> devices can use it. If this is the right path, then sysbus is
>> obsolescent.
>
> I do think that at some point it would be good to move
Re: QOM parent type "sys-bus-device" vs. "device" (was: [PATCH v2 12/13] hw/char/serial: Inherit from SysBusDevice)
On Wed, 4 Mar 2026, Peter Maydell wrote:
On Wed, 4 Mar 2026 at 12:25, Markus Armbruster wrote:
We might be at a crossroads here.
Paul Brook designed qdev around "a device plugs into some bus, and may
provide buses". To make this work, he added a main system bus to serve
as root of a single tree.
The parent of a device in that tree is the bus it plugs into, and the
parent of a bus is the device that provides it, except for the main
system bus, which has no parent. "info qtree" shows this tree.
Note a machine had just this one system bus back then.
The system bus isn't something hardware people would call a bus.
The qtree is a qdev thing. It is *not* the QOM composition tree ("info
qom-tree /").
We actually abandoned "a device plugs into some bus" a long time ago.
Moe on that below.
Qdev was later rebased onto QOM, as follows.
A bus QOM type is a subtype of "bus".
A device QOM type is a subtype of "device".
If a device type has a @bus_type, then it plugs into a bus of that QOM
type. Such a concrete device is commonly[*] not a direct subtype of
"device". Instead, it's a subtype of the abstract device that plugs
into that bus type. Example: "isa-serial" is a direct subtype of
"isa-device", and it inherits its bus type "ISA" from there.
If a device has no @bus_type, it doesn't plug into any bus. It doesn't
show up in "info qtree" (it does in "info qom-tree", of course).
Example: "serial" is a direct subtype of "device".
This lets us build devices from components without having to make up
buses to connect them. Example: "isa-serial" has a direct QOM child of
type "serial". Good!
Except infrastructure useful to such bus-less devices lives in sysbus,
where bus-less devices can't access it. This tempts us to make devices
sysbus devices just to be able to use the infrastructure, and to create
additional sysbuses.
There is only one sysbus -- it is impossible to create more than one,
and there wouldn't be much point in creating a second one anyway.
We can elect to go down this path further: make more sysbus devices.
Create more sysbuses. If this is the right path, then bus-less devices
were a mistake, and we should consider eliminating them.
Or we can pick the other branch: put the infrastructure where bus-less
devices can use it. If this is the right path, then sysbus is
obsolescent.
I do think that at some point it would be good to move all that
stuff into the base "device" class, and drop sysbus. The real
problem, though, is reset. Currently reset propagates along the
qtree (the tree of buses). So something (like TYPE_SERIAL, and
also like CPU objects) that is a direct child of TYPE_DEVICE does
not get automatically reset. The major overriding reason why
(as it currently stands) I favour making things sysbus devices
and not plain devices is that devices that don't get reset are
either broken or need all their users to take extra steps that
most don't take, or do in a weird way. We can't just push the
reset handling into TYPE_DEVICE because by definition it is tied
to "being a thing on a bus, i.e. the sysbus".
Disentangling reset is extremely painful -- I don't even know
what it ought to be doing. Maybe propagating along the QOM tree?
So for now, we muddle along.
This suggests maybe we need a way to represent qtree in QOM. So while QOM
devices are organised by parent-child relationship in the qom-tree they
could have standardised properties that tell which bus they are connected
to (or buses have properties that list devices connected to them,
whichever is easier to walk) then the reset or info qtree could select
devices based on these properties. Could that replace the qtree of sysbus
devices and thus allow merging SysBusDevice into Device? There are link
properties in QOM to connect objects so it should be possible to represent
object relationships with such properties not just by their parent-child
(which I think are also represented by properties but I did not check it).
Regards,
BALATON Zoltan
Re: QOM parent type "sys-bus-device" vs. "device" (was: [PATCH v2 12/13] hw/char/serial: Inherit from SysBusDevice)
On Wed, 4 Mar 2026 at 12:25, Markus Armbruster wrote:
> We might be at a crossroads here.
>
> Paul Brook designed qdev around "a device plugs into some bus, and may
> provide buses". To make this work, he added a main system bus to serve
> as root of a single tree.
>
> The parent of a device in that tree is the bus it plugs into, and the
> parent of a bus is the device that provides it, except for the main
> system bus, which has no parent. "info qtree" shows this tree.
>
> Note a machine had just this one system bus back then.
>
> The system bus isn't something hardware people would call a bus.
>
> The qtree is a qdev thing. It is *not* the QOM composition tree ("info
> qom-tree /").
>
> We actually abandoned "a device plugs into some bus" a long time ago.
> Moe on that below.
>
> Qdev was later rebased onto QOM, as follows.
>
> A bus QOM type is a subtype of "bus".
>
> A device QOM type is a subtype of "device".
>
> If a device type has a @bus_type, then it plugs into a bus of that QOM
> type. Such a concrete device is commonly[*] not a direct subtype of
> "device". Instead, it's a subtype of the abstract device that plugs
> into that bus type. Example: "isa-serial" is a direct subtype of
> "isa-device", and it inherits its bus type "ISA" from there.
>
> If a device has no @bus_type, it doesn't plug into any bus. It doesn't
> show up in "info qtree" (it does in "info qom-tree", of course).
> Example: "serial" is a direct subtype of "device".
>
> This lets us build devices from components without having to make up
> buses to connect them. Example: "isa-serial" has a direct QOM child of
> type "serial". Good!
>
> Except infrastructure useful to such bus-less devices lives in sysbus,
> where bus-less devices can't access it. This tempts us to make devices
> sysbus devices just to be able to use the infrastructure, and to create
> additional sysbuses.
There is only one sysbus -- it is impossible to create more than one,
and there wouldn't be much point in creating a second one anyway.
> We can elect to go down this path further: make more sysbus devices.
> Create more sysbuses. If this is the right path, then bus-less devices
> were a mistake, and we should consider eliminating them.
>
> Or we can pick the other branch: put the infrastructure where bus-less
> devices can use it. If this is the right path, then sysbus is
> obsolescent.
I do think that at some point it would be good to move all that
stuff into the base "device" class, and drop sysbus. The real
problem, though, is reset. Currently reset propagates along the
qtree (the tree of buses). So something (like TYPE_SERIAL, and
also like CPU objects) that is a direct child of TYPE_DEVICE does
not get automatically reset. The major overriding reason why
(as it currently stands) I favour making things sysbus devices
and not plain devices is that devices that don't get reset are
either broken or need all their users to take extra steps that
most don't take, or do in a weird way. We can't just push the
reset handling into TYPE_DEVICE because by definition it is tied
to "being a thing on a bus, i.e. the sysbus".
Disentangling reset is extremely painful -- I don't even know
what it ought to be doing. Maybe propagating along the QOM tree?
So for now, we muddle along.
-- PMM
