From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46743) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZEg6E-0002pz-6e for qemu-devel@nongnu.org; Mon, 13 Jul 2015 11:56:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZEg69-00021X-7v for qemu-devel@nongnu.org; Mon, 13 Jul 2015 11:56:58 -0400 Received: from mail-vn0-f48.google.com ([209.85.216.48]:37180) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZEg69-00021A-4i for qemu-devel@nongnu.org; Mon, 13 Jul 2015 11:56:53 -0400 Received: by vnav203 with SMTP id v203so26019637vna.4 for ; Mon, 13 Jul 2015 08:56:52 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20150713173858.1930cd71.cornelia.huck@de.ibm.com> References: <1436460692-5142-1-git-send-email-cornelia.huck@de.ibm.com> <1436460692-5142-2-git-send-email-cornelia.huck@de.ibm.com> <55A3AD6D.5010303@de.ibm.com> <20150713161152.3e519fcd.cornelia.huck@de.ibm.com> <55A3C919.1040400@suse.de> <55A3CB76.4070803@de.ibm.com> <55A3D3BB.3010508@suse.de> <20150713173858.1930cd71.cornelia.huck@de.ibm.com> From: Peter Maydell Date: Mon, 13 Jul 2015 16:56:33 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH for-2.4 1/2] core: reset handler for bus-less devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cornelia Huck Cc: Peter Crosthwaite , Alexander Graf , QEMU Developers , Christian Borntraeger , Jens Freimann , Xu Wang , =?UTF-8?Q?Andreas_F=C3=A4rber?= On 13 July 2015 at 16:38, Cornelia Huck wrote: > So why does a pure Device have a reset callback then that is not called > by default? This is (as I understand it) basically historical legacy from qdev. The qdev model puts every device on a bus of some kind, and then says that it's the bus that has responsibility for resetting the devices on it. We've now generalised that to allowing devices that don't really sit on buses, but because we still have a lot of code in the system that assumes the reset-is-by-the-bus model (and for cases like PCI depends on that ordering) we can't shift to "just reset every Device object in the system". So the current setup is that every Device needs to either (a) live on a bus that handles reset for it or (b) arrange to call reset itself or (c) require the code which creates it to arrange for reset to be called (which is what CPU objects do, for instance -- the board code has to register a reset handler which calls cpu_reset()). > Really, I think we're moving in circles here. First, the device should > not live on the sysbus as it does not fit the perceived sysbus > semantics. As there is no natural bus for it to live on, it becomes a > pure device. Which is not reset, because somehow a generic callback is > not called generically. I agree it's confusing, but I think adding a generic call to reset at this point in the release cycle is really dangerous. For better or worse, a lot of devices in the system expect to be reset in the way they are currently. There's definitely scope for improving/fixing the current code, but I think it's more upheaval than we can do for this release. thanks -- PMM