On Mon, 27 May 2019 at 08:52, Markus Armbruster <arm...@redhat.com> wrote: > > Peter Maydell <peter.mayd...@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
