[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [qemu-s390x] [Qemu-devel] hw/s390x/ipl: Dubious use of qdev_reset_al
From: |
Markus Armbruster |
Subject: |
Re: [qemu-s390x] [Qemu-devel] hw/s390x/ipl: Dubious use of qdev_reset_all_fn |
Date: |
Tue, 28 May 2019 07:02:43 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
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.
- Re: [qemu-s390x] hw/s390x/ipl: Dubious use of qdev_reset_all_fn, (continued)
- Re: [qemu-s390x] hw/s390x/ipl: Dubious use of qdev_reset_all_fn, David Hildenbrand, 2019/05/24
- Re: [qemu-s390x] hw/s390x/ipl: Dubious use of qdev_reset_all_fn, Christian Borntraeger, 2019/05/24
- Re: [qemu-s390x] hw/s390x/ipl: Dubious use of qdev_reset_all_fn, David Hildenbrand, 2019/05/24
- Re: [qemu-s390x] hw/s390x/ipl: Dubious use of qdev_reset_all_fn, David Hildenbrand, 2019/05/24
- Re: [qemu-s390x] hw/s390x/ipl: Dubious use of qdev_reset_all_fn, Christian Borntraeger, 2019/05/24
- Re: [qemu-s390x] hw/s390x/ipl: Dubious use of qdev_reset_all_fn, David Hildenbrand, 2019/05/24
- Re: [qemu-s390x] [Qemu-devel] hw/s390x/ipl: Dubious use of qdev_reset_all_fn, Peter Maydell, 2019/05/25
- Re: [qemu-s390x] [Qemu-devel] hw/s390x/ipl: Dubious use of qdev_reset_all_fn, Markus Armbruster, 2019/05/27
- Re: [qemu-s390x] [Qemu-devel] hw/s390x/ipl: Dubious use of qdev_reset_all_fn, Philippe Mathieu-Daudé, 2019/05/27
- Re: [qemu-s390x] [Qemu-devel] hw/s390x/ipl: Dubious use of qdev_reset_all_fn, Peter Maydell, 2019/05/27
- Re: [qemu-s390x] [Qemu-devel] hw/s390x/ipl: Dubious use of qdev_reset_all_fn,
Markus Armbruster <=
- Re: [qemu-s390x] [Qemu-devel] hw/s390x/ipl: Dubious use of qdev_reset_all_fn, Markus Armbruster, 2019/05/29
- Re: [qemu-s390x] [Qemu-devel] hw/s390x/ipl: Dubious use of qdev_reset_all_fn, Philippe Mathieu-Daudé, 2019/05/29
- Re: [qemu-s390x] hw/s390x/ipl: Dubious use of qdev_reset_all_fn, David Hildenbrand, 2019/05/28
- Re: [qemu-s390x] hw/s390x/ipl: Dubious use of qdev_reset_all_fn, Cornelia Huck, 2019/05/28
- Re: [qemu-s390x] hw/s390x/ipl: Dubious use of qdev_reset_all_fn, Philippe Mathieu-Daudé, 2019/05/28
Re: [qemu-s390x] hw/s390x/ipl: Dubious use of qdev_reset_all_fn, Philippe Mathieu-Daudé, 2019/05/24