On Mon, Aug 30, 2010 at 11:19 AM, Gleb Natapov <g...@redhat.com> 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: >> > On 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.html >> >> The summary is >> >> - warm reset is wanted in qemu >> >> - Pressing the reset button is a warm reset on real machines >> >> - Sparc64 CPU uses different reset vector for warm and cold reset, >> >> so system_reset acts like a reset button >> >> - Bus reset can be implemented utilizing qdev frame work instead of >> >> implemeting it each bus layer independently. >> >> - The modification should be incremental. >> >> Anthony would 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. >> >> >> >> >> >> If the direction is okay, The next step would be a patch(set) for qdev >> >> 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? Former 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.
Is warm reset similar to what happens to these when resuming from suspend? Or is there some additional signal to tell the device? Is there a spec for these things?