Re: [Qemu-devel] hw/s390x/ipl: Dubious use of qdev_reset_all_fn

[Peter Maydell <peter.maydell@linaro.org>]

On Fri, 24 May 2019 at 20:47, Christian Borntraeger
<borntraeger@de.ibm.com> wrote:
> While this patch is certainly ok, I find it disturbing that qdev devices are being resetted,
> but qom devices not.

It's not a qdev-vs-QOM thing. Anything which is a DeviceState
has a reset method, but only devices which are somewhere
rooted in the bus-tree that starts with the "main system
bus" (aka sysbus) get reset by the vl.c-registered "reset
everything on the system bus". Devices which are SysBusDevice
get auto-parented onto the sysbus, and so get reset. Devices
like PCI devices or SCSI devices get put onto the PCI
bus or the SCSI bus, and those buses are in turn children
of some host-controller device which is on the sysbus, so
they all get reset. The things that don't get reset are
"orphan" devices which are neither (a) of a type that gets
automatically parented onto a bus like SysBusDevice nor
(b) put specifically onto some other bus.

CPU objects are the other common thing that doesn't get
reset 'automatically'.

Suggestions for how to restructure reset so this doesn't
happen are welcome... "reset follows the bus hierarchy"
works well in some places but is a bit weird in others
(for SoC containers and the like "follow the QOM
hierarchy" would make more sense, but I have no idea
how to usefully transition to a model where you could
say "for these devices, follow QOM tree for reset" or
what an API for that would look like).

thanks
-- PMM