Peter Maydell <peter.mayd...@linaro.org> writes: > 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).
Can do. >> 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. You're right. >> 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. Sounds good.
