From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=56020 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OqSL6-0000xO-Od for qemu-devel@nongnu.org; Tue, 31 Aug 2010 11:01:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OqSKf-0007j8-R0 for qemu-devel@nongnu.org; Tue, 31 Aug 2010 11:01:10 -0400 Received: from mail-qy0-f173.google.com ([209.85.216.173]:34268) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OqSKf-0007iy-Oa for qemu-devel@nongnu.org; Tue, 31 Aug 2010 11:01:05 -0400 Received: by qyk34 with SMTP id 34so1016046qyk.4 for ; Tue, 31 Aug 2010 08:01:05 -0700 (PDT) Message-ID: <4C7D192B.7010302@codemonkey.ws> Date: Tue, 31 Aug 2010 10:00:59 -0500 From: Anthony Liguori 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> <4C7D0BCA.3050603@redhat.com> In-Reply-To: <4C7D0BCA.3050603@redhat.com> 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: Avi Kivity Cc: Gleb Natapov , glommer@redhat.com, qemu-devel@nongnu.org, blauwirbel@gmail.com, Isaku Yamahata , alex.williamson@redhat.com On 08/31/2010 09:03 AM, Avi Kivity wrote: > 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) That's my source of confusion. I know hardware does a custom transversal but from a functional perspective, do we care? So far, no one has answered this with, "yes, because device XX propagates in a specific ordering of child a, b, c, d..." which I take to mean that the answer is no. Regards, Anthony Liguori