From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48873 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OqJNB-0002Px-E0 for qemu-devel@nongnu.org; Tue, 31 Aug 2010 01:27:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OqJNA-0004jO-4b for qemu-devel@nongnu.org; Tue, 31 Aug 2010 01:27:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19745) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OqJN9-0004j7-TH for qemu-devel@nongnu.org; Tue, 31 Aug 2010 01:27:04 -0400 Date: Tue, 31 Aug 2010 08:26:59 +0300 From: Gleb Natapov Subject: Re: [Qemu-devel] Re: [PATCH 0/5] RFC: distinguish warm reset from cold reset. Message-ID: <20100831052659.GE10499@redhat.com> References: <4C7B64D7.2020703@redhat.com> <20100830083520.GA7402@valinux.co.jp> <20100830111909.GC10499@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Isaku Yamahata , alex.williamson@redhat.com, glommer@redhat.com, Avi Kivity , qemu-devel@nongnu.org On Mon, Aug 30, 2010 at 07:07:11PM +0000, Blue Swirl wrote: > On Mon, Aug 30, 2010 at 11:19 AM, Gleb Natapov wrote: > > On Mon, Aug 30, 2010 at 05:35:20PM +0900, Isaku Yamahata wrote: > >> On Mon, Aug 30, 2010 at 10:59:19AM +0300, Avi Kivity wrote: > >> > =9AOn 08/30/2010 10:49 AM, Isaku Yamahata wrote: > >> >> This patch set distinguish warm reset from cold reset by > >> >> introducing warm reset callback handler. > >> >> The first 4 patches are trivial clean up patches. The last patch of= 5/5 > >> >> is RFC patch. > >> >> > >> >> The following thread arose cold reset vs warm reset issues. > >> >> http://lists.nongnu.org/archive/html/qemu-devel/2010-08/msg00186.ht= ml > >> >> The summary is > >> >> - warm reset is wanted in qemu > >> >> =9A =9A- Pressing the reset button is a warm reset on real machines > >> >> =9A =9A- Sparc64 CPU uses different reset vector for warm and cold = reset, > >> >> =9A =9A =9Aso system_reset acts like a reset button > >> >> =9A =9A- Bus reset can be implemented utilizing qdev frame work ins= tead of > >> >> =9A =9A =9Aimplemeting it each bus layer independently. > >> >> - The modification should be incremental. > >> >> =9A =9AAnthony would like to see that as an incremental addition to= what we have > >> >> =9A =9Atoday (like introducing a propagating warm reset callback) a= nd thinking > >> >> =9A =9Athrough what the actual behavior should and shouldn't be. > >> >> > >> >> > >> >> If the direction is okay, The next step would be a patch(set) for q= dev which > >> >> would introduce qdev_cold_reset(), qdev_warm_reset(), > >> >> DeviceInfo::cold_reset and DeviceInfo::warm_reset > >> >> and would obsolete qdev_reset() and DeviceInfo::reset. > >> >> > >> > > >> > What would be the difference between warm and cold reset? =9AFormer = called > >> > on any reset, while the latter called on power up only? > >> > >> What I have in mind at the moment is, > >> warm reset callback is called on warm reset, not called on power up. > >> cold reset callback is called only on power up (and power cycle). > >> > > Why stop there. Why not implement proper power planes support. Some > > devices are not powered down on S3/S4 suspend for instance. >=20 > Is warm reset similar to what happens to these when resuming from > suspend? I would say cold reset is more similar to what happens during resume =66rom suspend for most devices since during suspend they do not have power at all. > Or is there some additional signal to tell the device? Is > there a spec for these things? Things are different from chipset to chipset. In piix4 spec there is chapter called Power Planes which describe power planes available and what is powered by them. -- Gleb.