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

[Markus Armbruster]

Peter Maydell <address@hidden> writes:

> On Mon, 27 May 2019 at 08:52, Markus Armbruster <address@hidden> wrote:
>>
>> Peter Maydell <address@hidden> 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.