From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=40211 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OqRRP-0002x6-TY for qemu-devel@nongnu.org; Tue, 31 Aug 2010 10:04:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OqRRO-00066x-E6 for qemu-devel@nongnu.org; Tue, 31 Aug 2010 10:03:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:17384) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OqRRO-00066k-4v for qemu-devel@nongnu.org; Tue, 31 Aug 2010 10:03:58 -0400 Message-ID: <4C7D0BCA.3050603@redhat.com> Date: Tue, 31 Aug 2010 17:03:54 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 5/5] RFC: distinguish warm reset from cold reset. References: <0a460e01cca4fa24f446c7a715fe6df17d0be9ed.1283152674.git.yamahata@valinux.co.jp> <4C7BAB2A.30608@codemonkey.ws> <20100831025808.GA19374@valinux.co.jp> <4C7CFEC1.8040204@codemonkey.ws> <20100831131449.GG10499@redhat.com> <4C7D01B3.4030602@codemonkey.ws> <20100831132158.GH10499@redhat.com> <4C7D02FB.4030706@codemonkey.ws> <4C7D03C7.9090406@redhat.com> <4C7D04E4.2060305@codemonkey.ws> <4C7D07B9.4090909@redhat.com> <4C7D0A6E.8000302@codemonkey.ws> In-Reply-To: <4C7D0A6E.8000302@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Gleb Natapov , glommer@redhat.com, qemu-devel@nongnu.org, blauwirbel@gmail.com, Isaku Yamahata , alex.williamson@redhat.com On 08/31/2010 04:58 PM, Anthony Liguori wrote: > On 08/31/2010 08:46 AM, Avi Kivity wrote: >> On 08/31/2010 04:34 PM, Anthony Liguori wrote: >>> On 08/31/2010 08:29 AM, Avi Kivity wrote: >>>> Note, for most devices there's no difference. x86 has INIT and >>>> RESET, with the keyboard controller RESET signal sometimes wired to >>>> INIT, and RAM doesn't have RESET. Otherwise most devices don't see >>>> a difference. >>> >>> Yes, that's why I'm wondering if we can just get away with using a >>> simple reset() callback and for the handful of devices that don't do >>> a full reset, they can just move the state unaffected by warm reset >>> to ->init(). >>> >> >> This seems reasonable. > > But I'm still not sure whether the reset signal can be deliver based > on a pre-order transversal or whether a custom transversal was > required that each bus participates in. There's no such thing as a global reset. There's a trace on the board that's called RESET that's connected to many chip's RESET input (but perhaps not all). A PCI bus controller will likely propagate its RESET input into the PCI reset signal, however it's called. So individual RESET traces are connected by chips, which have different conditions for asserting them. So yes, we need a custom traversal. Some bus controllers will block off RESET completely, some will pass it through, some can reset the devices on their bus independently of the controller's RESET input, if it has one. (but I think we're drifting off into pointlessness here) > >>> For cold reset, I'd rather approach it as a device destroy + >>> create. This means that given a DeviceState, we need to collect >>> enough information to recreate the device. I'm not 100% sure we >>> have that today but if we solve that problem, it means we can >>> migrate the device tree during migration which is a feature I'd >>> really like to see. >> >> Why do we need a cold reset at all? it doesn't map to anything. > > That's why I'm suggesting a second-class approach to implementing it > if someone really wants it. Sure. -- error compiling committee.c: too many arguments to function