Peter Maydell <[email protected]> writes:
> On Thu, 5 Mar 2026 at 09:25, Markus Armbruster <[email protected]> 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?
