[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 00/15] qdev: make reset semantics more clear and
From: |
Peter Maydell |
Subject: |
Re: [Qemu-devel] [PATCH 00/15] qdev: make reset semantics more clear and consistent, reset qbuses under virtio devices |
Date: |
Mon, 7 Jan 2013 19:57:20 +0000 |
On 7 January 2013 19:10, Anthony Liguori <address@hidden> wrote:
> Paolo Bonzini <address@hidden> writes:
>> 1) device-level reset is the kind of reset that you get with a register
>> write on the device. It will clear interrupts and DMAs among other things,
>> but not any bus-level state, for example it will not clear PCI BARs and
>> other configuration space data. It is done with qdev_reset_all.
This isn't really right -- often writing the register on the device will
reset some things but not the whole device state the way a qdev
reset does. qdev reset (to the extent it's modelling anything) is more
like yanking power to the device and reapplying it.
>> 2) bus-level reset is the kind of reset that you get with a register
>> write on the device that exports the bus (including triggering a device-level
>> reset on the device that exports the bus). It will do a device-level
>> reset on the child, but also clear bus-level state such as PCI BARs and
>> other configuration space data. It can be triggered for all devices
>> on a bus with qbus_reset_all. There is still no API for a bus-level
>> reset of a single device (like PCI FLR), this can be added later.
This doesn't sound very plausible: when would you do a bus level
reset anyway?
> I don't really understand this dual abstraction. I suspect it's
> overgeneralizing something that's the result of poor modeling.
Agreed.
> What I'm missing with this series is what problem are we trying to
> solve? I don't think we model reset correctly today because I don't
> think there's a single notion of reset.
Also agreed.
> I think reset really ought to just be a bus level concept with
> individual implementations for each bus.
I'm not sure I really agree here, especially since QOM/qdev are
moving away from the idea that there is a single bus tree and every
device is on a single bus. It's quite common for a bus to include a
reset signal but not all device reset is handled by a signal on a bus.
If we want to model reset properly we should model actual reset
lines (and/or power-cycling). If we don't care we can continue with
whatever fudge we like :-)
-- PMM
- Re: [Qemu-devel] [PATCH 00/15] qdev: make reset semantics more clear and consistent, reset qbuses under virtio devices, Anthony Liguori, 2013/01/07
- Re: [Qemu-devel] [PATCH 00/15] qdev: make reset semantics more clear and consistent, reset qbuses under virtio devices,
Peter Maydell <=
- Re: [Qemu-devel] [PATCH 00/15] qdev: make reset semantics more clear and consistent, reset qbuses under virtio devices, Paolo Bonzini, 2013/01/09
- Re: [Qemu-devel] [PATCH 00/15] qdev: make reset semantics more clear and consistent, reset qbuses under virtio devices, Michael S. Tsirkin, 2013/01/09
- Re: [Qemu-devel] [PATCH 00/15] qdev: make reset semantics more clear and consistent, reset qbuses under virtio devices, Paolo Bonzini, 2013/01/09
- Re: [Qemu-devel] [PATCH 00/15] qdev: make reset semantics more clear and consistent, reset qbuses under virtio devices, Michael S. Tsirkin, 2013/01/09
- Re: [Qemu-devel] [PATCH 00/15] qdev: make reset semantics more clear and consistent, reset qbuses under virtio devices, Paolo Bonzini, 2013/01/09
- Re: [Qemu-devel] [PATCH 00/15] qdev: make reset semantics more clear and consistent, reset qbuses under virtio devices, Michael S. Tsirkin, 2013/01/09
- Re: [Qemu-devel] [PATCH 00/15] qdev: make reset semantics more clear and consistent, reset qbuses under virtio devices, Paolo Bonzini, 2013/01/09