From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=33445 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OodS5-0004oF-6Q for qemu-devel@nongnu.org; Thu, 26 Aug 2010 10:29:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OodS3-0005YZ-Tc for qemu-devel@nongnu.org; Thu, 26 Aug 2010 10:29:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36639) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OodS3-0005YL-MA for qemu-devel@nongnu.org; Thu, 26 Aug 2010 10:29:11 -0400 Message-ID: <4C767A32.70802@redhat.com> Date: Thu, 26 Aug 2010 17:29:06 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] qdev: Reset hotplugged devices References: <20100803161914.15514.59304.stgit@localhost6.localdomain6> <1282308092.3860.0.camel@x201> <4C6EA5C9.8080700@codemonkey.ws> <20100825030752.GA14605@valinux.co.jp> <4C7512BF.9000805@codemonkey.ws> <4C7668FA.5080301@redhat.com> <4C766B50.50907@codemonkey.ws> In-Reply-To: <4C766B50.50907@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: qemu-devel@nongnu.org, Isaku Yamahata , Alex Williamson , glommer@redhat.com, Markus Armbruster On 08/26/2010 04:25 PM, Anthony Liguori wrote: > On 08/26/2010 08:15 AM, Avi Kivity wrote: >> On 08/25/2010 03:55 PM, Anthony Liguori wrote: >>> >>>> Maybe we can merge the patches. >>>> As for your patch, I have some comment. >>>> - bus itself may want its own handler. At lease pci bus needs it. >>>> And propagating reset signal to children is up to the bus >>>> controller. >>> >>> I disagree. Reset should be equivalent to power off + init and it's >>> not something that can be selectively propagated. >> >> Not all busses propagate reset - SCSI is an example (I think). >> > > We're talking about cold reset vs. warm reset. > > In the absence of passthrough, I'm struggling to see a useful use-case > with warm reset. However, there are many useful things we can do > assuming a cold reset (like MADV_DONTNEED memory on reboot). > > That's not saying we shouldn't do a warm reset, but I'd like to see > that as an incremental addition to what we have today (like > introducing a propagating warm reset callback) and thinking through > what the actual behavior should and shouldn't be. Pressing the reset button is a warm reset on real machines, therefore it should be a warm reset in qemu. -- error compiling committee.c: too many arguments to function