From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH 0/4] HVM Virtual S3 Date: Wed, 16 May 2007 23:29:55 +0100 Message-ID: References: <1104166E0B63A341805FDB977862AAD23BC750@pdsmsx414.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1104166E0B63A341805FDB977862AAD23BC750@pdsmsx414.ccr.corp.intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Yu, Ke" , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 16/5/07 17:48, "Yu, Ke" wrote: > - apply this patch to changeset 15050:05c128b0188a > - create and boot HVM domain > - In HVM guest, enter S3 state > * for Linux, "echo mem >/sys/power/state" > * for Windows, shutdown windows by Standby > - to resume HVM domain, "xm resume " Noone's seriously going to want to use S3-S5 in this way though, are they. Keeping domains hanging around in sleep states taking up memory doesn't make sense -- users will want to save the domain off to disc and restore later. So this only makes sense at all if integrated with existing HVM save/restore. As I understand it, the only difference between S3 and S5 is that RAM contents are maintained when the machine awakens. In this case S3 is like a simpler version of current save/restore where we do not necessarily need to save device state (but we might decide to if it makes the implementation easier). I think actually this isn't far off from being what we want. If the s3_suspend hypercall put the domain into suspend state, this would then neatly trigger xc_save to do its stuff. Then you can strip out s3_resume because you should automatically start executing BIOS code when xc_resume restores VCPU state and kicks the domain to start running again. The sleep_state domain variable you added shouldn't be necessary imo. -- Keir