RE: [Xen-devel] [PATCH 0/4] HVM Virtual S3

["Kaushik Barde" <Kaushik_Barde@xxxxxxxxxxx>]

I don't believe so.. We intend to use this support (with some additional
ACPI enhancements) as elaborated by Ke.


-Kaushik 

-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Keir Fraser
Sent: Wednesday, May 16, 2007 3:30 PM
To: Yu, Ke; xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] [PATCH 0/4] HVM Virtual S3

On 16/5/07 17:48, "Yu, Ke" <ke.yu@xxxxxxxxx> 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 <domid>"

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



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel