On 19/02/2016 00:07, Peter Crosthwaite wrote:
> On Thu, Feb 18, 2016 at 1:47 PM, Paolo Bonzini <pbonz...@redhat.com> wrote:
>>
>>
>> On 18/02/2016 10:56, Markus Armbruster wrote:
>>> Alistair Francis <alistair.fran...@xilinx.com> writes:
>>>
>>>> If the device being added when running qdev_device_add() has
>>>> a reset function, register it so that it can be called.
>>>>
>>>> Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com>
>>>> ---
>>>>
>>>> qdev-monitor.c | 2 ++
>>>> 1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/qdev-monitor.c b/qdev-monitor.c
>>>> index 81e3ff3..0a99d01 100644
>>>> --- a/qdev-monitor.c
>>>> +++ b/qdev-monitor.c
>>>> @@ -561,6 +561,8 @@ DeviceState *qdev_device_add(QemuOpts *opts, Error
>>>> **errp)
>>>>
>>>> if (bus) {
>>>> qdev_set_parent_bus(dev, bus);
>>>> + } else if (dc->reset) {
>>>> + qemu_register_reset((void (*)(void *))dc->reset, dev);
>>>> }
>>>>
>>>> id = qemu_opts_id(opts);
>>>
>>> This looks wrong to me.
>>>
>>> You stuff all the device reset methods into the global reset_handlers
>>> list, where they get called in some semi-random order. This breaks when
>>> there are reset order dependencies between devices, e.g. between a
>>> device and the bus it plugs into.
>>
>> There is no bus here, see the "if" above the one that's being added.
>>
>> However, what devices have done so far is to register/unregister the
>> reset in the realize/unrealize methods, and I suggest doing the same.
>
> Does this assume the device itself knows whether it is bus-connected
> or not? This way has the advantage of catchall-ing devices that have
> no bus connected and the device may or may not know whether it is
> bus-connected (nor should it need to know).
A device almost definitely needs to know if it is bus connected. More
likely than not, a busless device inherits from DeviceState while a
device with a bus inherits from SCSIDevice, PCIDevice, I2CSlave, etc.
> Probably doesn't have in
> tree precedent yet, but I thought we wanted to move away from
> qdev/qbus managing the device-tree. So ideally, the new else should
> become unconditional long term once we debusify (and properly QOMify)
> the reset tree (and the if goes away).
Any abstraction we have in QEMU should have at least a parallel (though
it need not be the same) in real hardware. Reset signals _do_ propagate
along buses, or at least along some buses, so "debusifying" reset seems
like a counterproductive goal to me.
For busless devices, I thought the idea was just to have the QOM parent
(container) propagate the realize/reset/unrealize signals in the right
order. Unfortunately reality is not quite as simple and indeed here
however you have a busless device that:
- doesn't have a container (the container is just /machine/unattached or
similar).
- triggers a reset for something else that is not contained in it (the
CPU) and even some DMA.
>> If you really want to add the magic qemu_register_reset, you should at
>> least do one of the following:
>>
>> * add a matching unregister (no idea where)
>
> You could add a boolean flag to DeviceState that is set by this
> registration. It can then be checked at unrealize to remove reset
> handler.
Yeah, I guess that would work. A few changes:
- you register the callback unconditionally for all busless devices,
using qdev_reset_all_fn instead of directly dc->reset
- you do it after the "realized" property has been set successfully.
Otherwise, a failed -device or device_add will also leave a dangling
callback.
- add a comment that this is because the callback is registered because
this is a busless _and_ container-less device
Paolo
