From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52125) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWhRW-0003J8-Jy for qemu-devel@nongnu.org; Fri, 19 Feb 2016 04:33:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aWhRR-00005g-Oc for qemu-devel@nongnu.org; Fri, 19 Feb 2016 04:33:42 -0500 Received: from mail-wm0-x232.google.com ([2a00:1450:400c:c09::232]:36060) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWhRR-00005S-FW for qemu-devel@nongnu.org; Fri, 19 Feb 2016 04:33:37 -0500 Received: by mail-wm0-x232.google.com with SMTP id g62so66959295wme.1 for ; Fri, 19 Feb 2016 01:33:37 -0800 (PST) Sender: Paolo Bonzini References: <4744c26fdfd911c44b58a9b6e1d0effc6cb39594.1455739133.git.alistair.francis@xilinx.com> <87lh6ijqa2.fsf@blackfin.pond.sub.org> <56C63C0D.8030501@redhat.com> From: Paolo Bonzini Message-ID: <56C6E16D.10605@redhat.com> Date: Fri, 19 Feb 2016 10:33:33 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v1 1/2] qdev-monitor.c: Register reset function if the device has one List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: Peter Maydell , Markus Armbruster , "qemu-devel@nongnu.org Developers" , Alistair Francis , Christopher Covington , =?UTF-8?Q?Andreas_F=c3=a4rber?= , Li Guang On 19/02/2016 00:07, Peter Crosthwaite wrote: > On Thu, Feb 18, 2016 at 1:47 PM, Paolo Bonzini wrote: >> >> >> On 18/02/2016 10:56, Markus Armbruster wrote: >>> Alistair Francis 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 >>>> --- >>>> >>>> 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