From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60562 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OogQp-0000Mh-23 for qemu-devel@nongnu.org; Thu, 26 Aug 2010 13:40:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OogQY-0007BR-VG for qemu-devel@nongnu.org; Thu, 26 Aug 2010 13:39:52 -0400 Received: from mail-qy0-f173.google.com ([209.85.216.173]:63784) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OogQY-0007BM-T9 for qemu-devel@nongnu.org; Thu, 26 Aug 2010 13:39:50 -0400 Received: by qyk5 with SMTP id 5so6580809qyk.4 for ; Thu, 26 Aug 2010 10:39:50 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4C767A32.70802@redhat.com> 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> <4C767A32.70802@redhat.com> From: Blue Swirl Date: Thu, 26 Aug 2010 17:39:30 +0000 Message-ID: Subject: Re: [Qemu-devel] [PATCH] qdev: Reset hotplugged devices Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: glommer@redhat.com, qemu-devel@nongnu.org, Markus Armbruster , Isaku Yamahata , Alex Williamson On Thu, Aug 26, 2010 at 2:29 PM, Avi Kivity wrote: > =C2=A0On 08/26/2010 04:25 PM, Anthony Liguori wrote: >> >> On 08/26/2010 08:15 AM, Avi Kivity wrote: >>> >>> =C2=A0On 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. >>>>> =C2=A0 And propagating reset signal to children is up to the bus cont= roller. >>>> >>>> I disagree. =C2=A0Reset should be equivalent to power off + init and i= t'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. =C2=A0However, there are many useful things we can do a= ssuming 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. I agree. For example Sparc64 CPU uses different reset vector for warm and cold reset, so system_reset acts like a reset button. But most real life chips have only one reset signal pin, CPUs may be the only cases where multiple reset signals are used. I think current system_reset matches the need well. For most devices, system_reset initiates the same procedure for cold or warm reset. Those devices which care about warm reset can count the number of the resets. The only problem I see is that there is no way to signal cold reset or power cycle. Then there are devices which don't have reset signals at all, like RAM. Their behavior at reset is different compared to power cycling. Stateless hardware like ROMs do not care about either.