Re: [Qemu-devel] [PATCH 00/15] qdev: make reset semantics more clear and consistent, reset qbuses under virtio devices

[Anthony Liguori <aliguori@us.ibm.com>]

Peter Maydell <peter.maydell@linaro.org> writes:

> On 7 January 2013 19:10, Anthony Liguori <aliguori@us.ibm.com> wrote:
>> Paolo Bonzini <pbonzini@redhat.com> 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.

I don't mean a BusState level concept, I mean a PCIBus concept.

There is clearly such a thing as a PCI bus reset.  In fact, there are
multiple types of PCI bus resets.  There should be a PCIBus method that
calls out to PCIDevices on the bus.

But that isn't something that should be fitted into generalized to a
BusState::reset method.

> 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.

Agreed.

>
> 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 :-)

Yes, and that's basically what qemu_system_reset() is.  Of course, we
model it like everything is directly connected to a single power source
which is true 99% of the time.  That's why we've gotten away with it for
so long.

Regards,

Anthony Liguori

> -- PMM