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

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

On Mon, 27 May 2019 at 08:52, Markus Armbruster <armbru@redhat.com> wrote:
>
> Peter Maydell <peter.maydell@linaro.org> writes:
> > 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).
>
> Here's a QOM composition tree for the ARM virt machine (-nodefaults
> -device e1000) as visible in qom-fuse under /machine, with irq and
> qemu:memory-region ommitted for brevity:

virt is a bit of an outlier because as a purely-virtual
machine it has no "SoC" -- it's just a bag of devices
at the machine level. It would be interesting to
also look at a machine that's emulating something
closer to real hardware (eg one of the aspeed machines,
or mps2-an521).

> Observations:
>
> * Composition tree root machine's containers are not in the qtree.
>
> * Composition tree node cortex-a15-arm-cpu is not in the qtree.  That's
>   because it's not a qdev (in QOM parlance: not a TYPE_DEVICE).

Hmm? The Arm CPUs all subclass CPUClass, which subclasses
DeviceState. The CPU is a qdev, but it is not in the qtree because
it does not have a bus it can live on.

> Now let me ramble a bit on reset.

Thanks for this -- I have put this on my list to
think through in detail next week.

-- PMM