Shriram Rajagopalan
2011-Feb-14 16:21 UTC
[Xen-devel] [PATCH] Use freeze/thaw/restore PM events for Guest suspend/resume/checkpoint
Use PM_FREEZE, PM_THAW and PM_RESTORE power events for
suspend/resume functionality, instead of PM_SUSPEND and
PM_RESUME. Use of these pm events also fixes the Xen Guest
hangup when taking checkpoints. When a suspend event is cancelled
(i.e. while taking checkpoints once/continuously), we use PM_THAW
instead of PM_RESUME. PM_RESTORE is used when suspend is not
cancelled. See Documentation/power/devices.txt and linux/pm.h
for more info about freeze, thaw and restore. The sequence of
pm events in a suspend-resume scenario is shown below.
dpm_suspend_start(PMSG_FREEZE);
dpm_suspend_noirq(PMSG_FREEZE);
sysdev_suspend(PMSG_FREEZE);
cancelled = suspend_hypercall()
sysdev_resume();
dpm_resume_noirq(cancelled ? PMSG_THAW : PMSG_RESTORE);
dpm_resume_end(cancelled ? PMSG_THAW : PMSG_RESTORE);
Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
---
drivers/net/xen-netfront.c | 2 +-
drivers/xen/manage.c | 12 ++++++------
drivers/xen/xenbus/xenbus_probe.c | 11 +++++++++--
drivers/xen/xenbus/xenbus_probe.h | 3 ++-
drivers/xen/xenbus/xenbus_probe_frontend.c | 10 ++++++++--
include/xen/xenbus.h | 2 +-
6 files changed, 27 insertions(+), 13 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 3f71199..22c6288 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1293,7 +1293,7 @@ static void xennet_disconnect_backend(struct netfront_info
*info)
info->rx.sring = NULL;
}
-static int netfront_suspend(struct xenbus_device *dev, pm_message_t state)
+static int netfront_suspend(struct xenbus_device *dev)
{
struct netfront_info *info = dev_get_drvdata(&dev->dev);
struct hrtimer *timer = &info->smart_poll.timer;
diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
index 0b50906..98c856b 100644
--- a/drivers/xen/manage.c
+++ b/drivers/xen/manage.c
@@ -60,7 +60,7 @@ static int xen_suspend(void *data)
BUG_ON(!irqs_disabled());
- err = sysdev_suspend(PMSG_SUSPEND);
+ err = sysdev_suspend(PMSG_FREEZE);
if (err) {
printk(KERN_ERR "xen_suspend: sysdev_suspend failed: %d\n",
err);
@@ -117,16 +117,16 @@ static void do_suspend(void)
}
#endif
- err = dpm_suspend_start(PMSG_SUSPEND);
+ err = dpm_suspend_start(PMSG_FREEZE);
if (err) {
printk(KERN_ERR "xen suspend: dpm_suspend_start %d\n", err);
goto out_thaw;
}
- printk(KERN_DEBUG "suspending xenstore...\n");
+ /* printk(KERN_DEBUG "suspending xenstore...\n"); */
xs_suspend();
- err = dpm_suspend_noirq(PMSG_SUSPEND);
+ err = dpm_suspend_noirq(PMSG_FREEZE);
if (err) {
printk(KERN_ERR "dpm_suspend_noirq failed: %d\n", err);
goto out_resume;
@@ -137,7 +137,7 @@ static void do_suspend(void)
else
err = stop_machine(xen_suspend, &cancelled, cpumask_of(0));
- dpm_resume_noirq(PMSG_RESUME);
+ dpm_resume_noirq(cancelled ? PMSG_THAW : PMSG_RESTORE);
if (err) {
printk(KERN_ERR "failed to start xen_suspend: %d\n", err);
@@ -151,7 +151,7 @@ out_resume:
} else
xs_suspend_cancel();
- dpm_resume_end(PMSG_RESUME);
+ dpm_resume_end(cancelled ? PMSG_THAW : PMSG_RESTORE);
/* Make sure timer events get retriggered on all CPUs */
clock_was_set();
diff --git a/drivers/xen/xenbus/xenbus_probe.c
b/drivers/xen/xenbus/xenbus_probe.c
index 3a83ba2..b61b9f8 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -575,7 +575,7 @@ void xenbus_dev_changed(const char *node, struct
xen_bus_type *bus)
}
EXPORT_SYMBOL_GPL(xenbus_dev_changed);
-int xenbus_dev_suspend(struct device *dev, pm_message_t state)
+int xenbus_dev_suspend(struct device *dev)
{
int err = 0;
struct xenbus_driver *drv;
@@ -587,7 +587,7 @@ int xenbus_dev_suspend(struct device *dev, pm_message_t
state)
return 0;
drv = to_xenbus_driver(dev->driver);
if (drv->suspend)
- err = drv->suspend(xdev, state);
+ err = drv->suspend(xdev);
if (err)
printk(KERN_WARNING
"xenbus: suspend %s failed: %i\n", dev_name(dev), err);
@@ -638,6 +638,13 @@ int xenbus_dev_resume(struct device *dev)
}
EXPORT_SYMBOL_GPL(xenbus_dev_resume);
+int xenbus_dev_cancel(struct device *dev)
+{
+ /* Do nothing */
+ return 0;
+}
+EXPORT_SYMBOL_GPL(xenbus_dev_cancel);
+
/* A flag to determine if xenstored is ''ready'' (i.e. has
started) */
int xenstored_ready = 0;
diff --git a/drivers/xen/xenbus/xenbus_probe.h
b/drivers/xen/xenbus/xenbus_probe.h
index 0e5fc4c..4019187 100644
--- a/drivers/xen/xenbus/xenbus_probe.h
+++ b/drivers/xen/xenbus/xenbus_probe.h
@@ -62,8 +62,9 @@ extern void xenbus_dev_changed(const char *node, struct
xen_bus_type *bus);
extern void xenbus_dev_shutdown(struct device *_dev);
-extern int xenbus_dev_suspend(struct device *dev, pm_message_t state);
+extern int xenbus_dev_suspend(struct device *dev);
extern int xenbus_dev_resume(struct device *dev);
+extern int xenbus_dev_cancel(struct device *dev);
extern void xenbus_otherend_changed(struct xenbus_watch *watch,
const char **vec, unsigned int len,
diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c
b/drivers/xen/xenbus/xenbus_probe_frontend.c
index 5413248..ff32ffb 100644
--- a/drivers/xen/xenbus/xenbus_probe_frontend.c
+++ b/drivers/xen/xenbus/xenbus_probe_frontend.c
@@ -82,6 +82,13 @@ static struct device_attribute xenbus_frontend_dev_attrs[] =
{
__ATTR_NULL
};
+static struct dev_pm_ops xenbus_pm_ops = {
+ .suspend = xenbus_dev_suspend,
+ .resume = xenbus_dev_resume,
+ .freeze = xenbus_dev_suspend,
+ .thaw = xenbus_dev_cancel,
+ .restore = xenbus_dev_resume,
+};
static struct xen_bus_type xenbus_frontend = {
.root = "device",
@@ -98,8 +105,7 @@ static struct xen_bus_type xenbus_frontend = {
.shutdown = xenbus_dev_shutdown,
.dev_attrs= xenbus_frontend_dev_attrs,
- .suspend = xenbus_dev_suspend,
- .resume = xenbus_dev_resume,
+ .pm = &xenbus_pm_ops,
},
};
diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h
index 542ca7c..23e7f25 100644
--- a/include/xen/xenbus.h
+++ b/include/xen/xenbus.h
@@ -91,7 +91,7 @@ struct xenbus_driver {
void (*otherend_changed)(struct xenbus_device *dev,
enum xenbus_state backend_state);
int (*remove)(struct xenbus_device *dev);
- int (*suspend)(struct xenbus_device *dev, pm_message_t state);
+ int (*suspend)(struct xenbus_device *dev);
int (*resume)(struct xenbus_device *dev);
int (*uevent)(struct xenbus_device *, struct kobj_uevent_env *);
struct device_driver driver;
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Shriram Rajagopalan
2011-Feb-14 16:24 UTC
Re: [Xen-devel] [PATCH] Use freeze/thaw/restore PM events for Guest suspend/resume/checkpoint
On Mon, Feb 14, 2011 at 8:21 AM, Shriram Rajagopalan <rshriram@cs.ubc.ca> wrote:> Use PM_FREEZE, PM_THAW and PM_RESTORE power events for > suspend/resume functionality, instead of PM_SUSPEND and > PM_RESUME. Use of these pm events also fixes the Xen Guest > hangup when taking checkpoints. When a suspend event is cancelled > (i.e. while taking checkpoints once/continuously), we use PM_THAW > instead of PM_RESUME. PM_RESTORE is used when suspend is not > cancelled. See Documentation/power/devices.txt and linux/pm.h > for more info about freeze, thaw and restore. The sequence of > pm events in a suspend-resume scenario is shown below. > > dpm_suspend_start(PMSG_FREEZE); > > dpm_suspend_noirq(PMSG_FREEZE); > > sysdev_suspend(PMSG_FREEZE); > cancelled = suspend_hypercall() > sysdev_resume(); > > dpm_resume_noirq(cancelled ? PMSG_THAW : PMSG_RESTORE); > > dpm_resume_end(cancelled ? PMSG_THAW : PMSG_RESTORE); > > Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca> > --- > drivers/net/xen-netfront.c | 2 +- > drivers/xen/manage.c | 12 ++++++------ > drivers/xen/xenbus/xenbus_probe.c | 11 +++++++++-- > drivers/xen/xenbus/xenbus_probe.h | 3 ++- > drivers/xen/xenbus/xenbus_probe_frontend.c | 10 ++++++++-- > include/xen/xenbus.h | 2 +- > 6 files changed, 27 insertions(+), 13 deletions(-) > > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c > index 3f71199..22c6288 100644 > --- a/drivers/net/xen-netfront.c > +++ b/drivers/net/xen-netfront.c > @@ -1293,7 +1293,7 @@ static void xennet_disconnect_backend(struct netfront_info *info) > info->rx.sring = NULL; > } > > -static int netfront_suspend(struct xenbus_device *dev, pm_message_t state) > +static int netfront_suspend(struct xenbus_device *dev) > { > struct netfront_info *info = dev_get_drvdata(&dev->dev); > struct hrtimer *timer = &info->smart_poll.timer; > diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c > index 0b50906..98c856b 100644 > --- a/drivers/xen/manage.c > +++ b/drivers/xen/manage.c > @@ -60,7 +60,7 @@ static int xen_suspend(void *data) > > BUG_ON(!irqs_disabled()); > > - err = sysdev_suspend(PMSG_SUSPEND); > + err = sysdev_suspend(PMSG_FREEZE); > if (err) { > printk(KERN_ERR "xen_suspend: sysdev_suspend failed: %d\n", > err); > @@ -117,16 +117,16 @@ static void do_suspend(void) > } > #endif > > - err = dpm_suspend_start(PMSG_SUSPEND); > + err = dpm_suspend_start(PMSG_FREEZE); > if (err) { > printk(KERN_ERR "xen suspend: dpm_suspend_start %d\n", err); > goto out_thaw; > } > > - printk(KERN_DEBUG "suspending xenstore...\n"); > + /* printk(KERN_DEBUG "suspending xenstore...\n"); */ > xs_suspend(); > > - err = dpm_suspend_noirq(PMSG_SUSPEND); > + err = dpm_suspend_noirq(PMSG_FREEZE); > if (err) { > printk(KERN_ERR "dpm_suspend_noirq failed: %d\n", err); > goto out_resume; > @@ -137,7 +137,7 @@ static void do_suspend(void) > else > err = stop_machine(xen_suspend, &cancelled, cpumask_of(0)); > > - dpm_resume_noirq(PMSG_RESUME); > + dpm_resume_noirq(cancelled ? PMSG_THAW : PMSG_RESTORE); > > if (err) { > printk(KERN_ERR "failed to start xen_suspend: %d\n", err); > @@ -151,7 +151,7 @@ out_resume: > } else > xs_suspend_cancel(); > > - dpm_resume_end(PMSG_RESUME); > + dpm_resume_end(cancelled ? PMSG_THAW : PMSG_RESTORE); > > /* Make sure timer events get retriggered on all CPUs */ > clock_was_set(); > diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c > index 3a83ba2..b61b9f8 100644 > --- a/drivers/xen/xenbus/xenbus_probe.c > +++ b/drivers/xen/xenbus/xenbus_probe.c > @@ -575,7 +575,7 @@ void xenbus_dev_changed(const char *node, struct xen_bus_type *bus) > } > EXPORT_SYMBOL_GPL(xenbus_dev_changed); > > -int xenbus_dev_suspend(struct device *dev, pm_message_t state) > +int xenbus_dev_suspend(struct device *dev) > { > int err = 0; > struct xenbus_driver *drv; > @@ -587,7 +587,7 @@ int xenbus_dev_suspend(struct device *dev, pm_message_t state) > return 0; > drv = to_xenbus_driver(dev->driver); > if (drv->suspend) > - err = drv->suspend(xdev, state); > + err = drv->suspend(xdev); > if (err) > printk(KERN_WARNING > "xenbus: suspend %s failed: %i\n", dev_name(dev), err); > @@ -638,6 +638,13 @@ int xenbus_dev_resume(struct device *dev) > } > EXPORT_SYMBOL_GPL(xenbus_dev_resume); > > +int xenbus_dev_cancel(struct device *dev) > +{ > + /* Do nothing */ > + return 0; > +} > +EXPORT_SYMBOL_GPL(xenbus_dev_cancel); > + > /* A flag to determine if xenstored is ''ready'' (i.e. has started) */ > int xenstored_ready = 0; > > diff --git a/drivers/xen/xenbus/xenbus_probe.h b/drivers/xen/xenbus/xenbus_probe.h > index 0e5fc4c..4019187 100644 > --- a/drivers/xen/xenbus/xenbus_probe.h > +++ b/drivers/xen/xenbus/xenbus_probe.h > @@ -62,8 +62,9 @@ extern void xenbus_dev_changed(const char *node, struct xen_bus_type *bus); > > extern void xenbus_dev_shutdown(struct device *_dev); > > -extern int xenbus_dev_suspend(struct device *dev, pm_message_t state); > +extern int xenbus_dev_suspend(struct device *dev); > extern int xenbus_dev_resume(struct device *dev); > +extern int xenbus_dev_cancel(struct device *dev); > > extern void xenbus_otherend_changed(struct xenbus_watch *watch, > const char **vec, unsigned int len, > diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c b/drivers/xen/xenbus/xenbus_probe_frontend.c > index 5413248..ff32ffb 100644 > --- a/drivers/xen/xenbus/xenbus_probe_frontend.c > +++ b/drivers/xen/xenbus/xenbus_probe_frontend.c > @@ -82,6 +82,13 @@ static struct device_attribute xenbus_frontend_dev_attrs[] = { > __ATTR_NULL > }; > > +static struct dev_pm_ops xenbus_pm_ops = { > + .suspend = xenbus_dev_suspend, > + .resume = xenbus_dev_resume, > + .freeze = xenbus_dev_suspend, > + .thaw = xenbus_dev_cancel, > + .restore = xenbus_dev_resume, > +}; > > static struct xen_bus_type xenbus_frontend = { > .root = "device", > @@ -98,8 +105,7 @@ static struct xen_bus_type xenbus_frontend = { > .shutdown = xenbus_dev_shutdown, > .dev_attrs= xenbus_frontend_dev_attrs, > > - .suspend = xenbus_dev_suspend, > - .resume = xenbus_dev_resume, > + .pm = &xenbus_pm_ops, > }, > }; > > diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h > index 542ca7c..23e7f25 100644 > --- a/include/xen/xenbus.h > +++ b/include/xen/xenbus.h > @@ -91,7 +91,7 @@ struct xenbus_driver { > void (*otherend_changed)(struct xenbus_device *dev, > enum xenbus_state backend_state); > int (*remove)(struct xenbus_device *dev); > - int (*suspend)(struct xenbus_device *dev, pm_message_t state); > + int (*suspend)(struct xenbus_device *dev); > int (*resume)(struct xenbus_device *dev); > int (*uevent)(struct xenbus_device *, struct kobj_uevent_env *); > struct device_driver driver; > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >parts of this patch were based on Kazuhiro Suzuki''s initial patch to fix the same issue. Refer to http://lists.xensource.com/archives/html/xen-devel/2011-02/msg00371.html for further details. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-Feb-14 19:06 UTC
Re: [Xen-devel] [PATCH] Use freeze/thaw/restore PM events for Guest suspend/resume/checkpoint
On Mon, 2011-02-14 at 16:21 +0000, Shriram Rajagopalan wrote:> Use PM_FREEZE, PM_THAW and PM_RESTORE power events for > suspend/resume functionality, instead of PM_SUSPEND and > PM_RESUME. Use of these pm events also fixes the Xen Guest > hangup when taking checkpoints. When a suspend event is cancelled > (i.e. while taking checkpoints once/continuously), we use PM_THAW > instead of PM_RESUME. PM_RESTORE is used when suspend is not > cancelled. See Documentation/power/devices.txt and linux/pm.h > for more info about freeze, thaw and restore. The sequence of > pm events in a suspend-resume scenario is shown below. > > dpm_suspend_start(PMSG_FREEZE); > > dpm_suspend_noirq(PMSG_FREEZE); > > sysdev_suspend(PMSG_FREEZE); > cancelled = suspend_hypercall() > sysdev_resume(); > > dpm_resume_noirq(cancelled ? PMSG_THAW : PMSG_RESTORE); > > dpm_resume_end(cancelled ? PMSG_THAW : PMSG_RESTORE);Thanks. Which tree/branch is this against? Can you please at least do the dev_pm_ops as a separate patch to allow bisectability etc. (generally each patch should be a single logical change so if the remaineder can be sensibly split too it is worth doing so). Did you test regular save/restore as well as cancelled migrations? What about PVHMV guests?> +static struct dev_pm_ops xenbus_pm_ops = { > + .suspend = xenbus_dev_suspend, > + .resume = xenbus_dev_resume, > + .freeze = xenbus_dev_suspend, > + .thaw = xenbus_dev_cancel, > + .restore = xenbus_dev_resume, > +};Perhaps xenbus_dev_thaw? Are suspend/freeze and resume/restore really the same? Once we''ve transitioned to the PMSG_FREEZE way of doing things do we still need to keep the other hooks around? If not then the other ones could be renamed as well? On Mon, 2011-02-14 at 16:24 +0000, Shriram Rajagopalan wrote:> parts of this patch were based on Kazuhiro Suzuki''s initial patch to > fix the same issue. Refer to > http://lists.xensource.com/archives/html/xen-devel/2011-02/msg00371.html > for further details.It''s worth mentioning this in the commit message, also please CC Kazuhiro since he has been working on this too, has a repro scenario etc. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Shriram Rajagopalan
2011-Feb-14 21:47 UTC
Re: [Xen-devel] [PATCH] Use freeze/thaw/restore PM events for Guest suspend/resume/checkpoint
On Mon, Feb 14, 2011 at 11:06 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:> On Mon, 2011-02-14 at 16:21 +0000, Shriram Rajagopalan wrote: >> Use PM_FREEZE, PM_THAW and PM_RESTORE power events for >> suspend/resume functionality, instead of PM_SUSPEND and >> PM_RESUME. Use of these pm events also fixes the Xen Guest >> hangup when taking checkpoints. When a suspend event is cancelled >> (i.e. while taking checkpoints once/continuously), we use PM_THAW >> instead of PM_RESUME. PM_RESTORE is used when suspend is not >> cancelled. See Documentation/power/devices.txt and linux/pm.h >> for more info about freeze, thaw and restore. The sequence of >> pm events in a suspend-resume scenario is shown below. >> >> dpm_suspend_start(PMSG_FREEZE); >> >> dpm_suspend_noirq(PMSG_FREEZE); >> >> sysdev_suspend(PMSG_FREEZE); >> cancelled = suspend_hypercall() >> sysdev_resume(); >> >> dpm_resume_noirq(cancelled ? PMSG_THAW : PMSG_RESTORE); >> >> dpm_resume_end(cancelled ? PMSG_THAW : PMSG_RESTORE); > > Thanks. > > Which tree/branch is this against? >Oh I thought that info be present in the git indices "index 5413248..ff32ffb 100644" . Its against my local git branch (which tracks xen/stable-2.6.32.x and is uptodate). Sorry, I am still a bit of git newbie.> Can you please at least do the dev_pm_ops as a separate patch to allow > bisectability etc. (generally each patch should be a single logical > change so if the remaineder can be sensibly split too it is worth doing > so). >ok> Did you test regular save/restore as well as cancelled migrations? What > about PVHMV guests? > >> +static struct dev_pm_ops xenbus_pm_ops = { >> + .suspend = xenbus_dev_suspend, >> + .resume = xenbus_dev_resume, >> + .freeze = xenbus_dev_suspend, >> + .thaw = xenbus_dev_cancel, >> + .restore = xenbus_dev_resume, >> +}; > > Perhaps xenbus_dev_thaw? > > Are suspend/freeze and resume/restore really the same? >Semantically they are not. From the documentation in pm.h, suspend/resume events deal with change in sleep states. Devices are quiesced on suspend and might go to lower power mode. (==> xm suspend/resume ?) freeze/thaw/restore are used for hibernation. freeze:save state to memory before hibernation, quiesce device but do not change power state. thaw: undo changes made by freeze, if hibernation fails. restore: restore device state from hibernation image (==> xm save/restore/checkpoint) I looked at xen frontend drivers (blkfront, netfront, etc). They only use the resume handler to teardown and re-establishe contact with backend. So, in our case, suspend/freeze and resume/restore are basically same. suspend-cancel is a thaw event.> Once we''ve transitioned to the PMSG_FREEZE way of doing things do we > still need to keep the other hooks around? If not then the other ones > could be renamed as well? >If your question is whether we can change static struct dev_pm_ops xenbus_pm_ops = { .suspend = xenbus_dev_suspend, .resume = xenbus_dev_resume, .freeze = xenbus_dev_suspend, .thaw = xenbus_dev_cancel, .restore = xenbus_dev_resume, }; to just static struct dev_pm_ops xenbus_pm_ops = { .freeze = xenbus_dev_freeze, .thaw = xenbus_dev_thaw, .restore = xenbus_dev_restore, }; then the answer is no, AFAICS, from the code in drivers/base/power/main.c (pm_op function).> On Mon, 2011-02-14 at 16:24 +0000, Shriram Rajagopalan wrote: >> parts of this patch were based on Kazuhiro Suzuki''s initial patch to >> fix the same issue. Refer to >> http://lists.xensource.com/archives/html/xen-devel/2011-02/msg00371.html >> for further details. > > It''s worth mentioning this in the commit message, also please CC > Kazuhiro since he has been working on this too, has a repro scenario > etc.will do.> > Ian. > >shriram _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-Feb-15 09:41 UTC
Re: [Xen-devel] [PATCH] Use freeze/thaw/restore PM events for Guest suspend/resume/checkpoint
On Mon, 2011-02-14 at 21:47 +0000, Shriram Rajagopalan wrote:> On Mon, Feb 14, 2011 at 11:06 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote: > > On Mon, 2011-02-14 at 16:21 +0000, Shriram Rajagopalan wrote: > >> Use PM_FREEZE, PM_THAW and PM_RESTORE power events for > >> suspend/resume functionality, instead of PM_SUSPEND and > >> PM_RESUME. Use of these pm events also fixes the Xen Guest > >> hangup when taking checkpoints. When a suspend event is cancelled > >> (i.e. while taking checkpoints once/continuously), we use PM_THAW > >> instead of PM_RESUME. PM_RESTORE is used when suspend is not > >> cancelled. See Documentation/power/devices.txt and linux/pm.h > >> for more info about freeze, thaw and restore. The sequence of > >> pm events in a suspend-resume scenario is shown below. > >> > >> dpm_suspend_start(PMSG_FREEZE); > >> > >> dpm_suspend_noirq(PMSG_FREEZE); > >> > >> sysdev_suspend(PMSG_FREEZE); > >> cancelled = suspend_hypercall() > >> sysdev_resume(); > >> > >> dpm_resume_noirq(cancelled ? PMSG_THAW : PMSG_RESTORE); > >> > >> dpm_resume_end(cancelled ? PMSG_THAW : PMSG_RESTORE); > > > > Thanks. > > > > Which tree/branch is this against? > > > Oh I thought that info be present in the git indices > "index 5413248..ff32ffb 100644" .I think those are the indices of the actual versions of the file, rather than the tree->commit->branch which contains them. I''m sure you could map up that chain but suspect it''d be a rather brute force affair.> Its against my local git branch (which tracks xen/stable-2.6.32.x and > is uptodate).In general we''d prefer to get this sort of thing fixed in the mainline kernel (e.g. Linus'' tree) first and then consider backports to the stable branch as necessary.> Sorry, I am still a bit of git newbie.No problem.> > Can you please at least do the dev_pm_ops as a separate patch to > > allow bisectability etc. (generally each patch should be a single > > logical change so if the remaineder can be sensibly split too it is > > worth doing so).> okYou can probably take Kazuhiro''s first patch verbatim for this bit? If you save the mail to a file you can apply it with "git am < foo.mail" and git will preserve authorship attribution etc and this will persist through "git format-patch" and "git send-email" etc.> > Did you test regular save/restore as well as cancelled migrations? What > > about PVHMV guests? > > > >> +static struct dev_pm_ops xenbus_pm_ops = { > >> + .suspend = xenbus_dev_suspend, > >> + .resume = xenbus_dev_resume, > >> + .freeze = xenbus_dev_suspend, > >> + .thaw = xenbus_dev_cancel, > >> + .restore = xenbus_dev_resume, > >> +}; > > > > Perhaps xenbus_dev_thaw? > > > > Are suspend/freeze and resume/restore really the same? > > > Semantically they are not. From the documentation in pm.h,[...]> So, in our case, suspend/freeze and resume/restore are basically same. > suspend-cancel is a thaw event.OK.> > Once we''ve transitioned to the PMSG_FREEZE way of doing things do we > > still need to keep the other hooks around? If not then the other ones > > could be renamed as well? > > > If your question is whether we can change > static struct dev_pm_ops xenbus_pm_ops = { > .suspend = xenbus_dev_suspend, > .resume = xenbus_dev_resume, > .freeze = xenbus_dev_suspend, > .thaw = xenbus_dev_cancel, > .restore = xenbus_dev_resume, > }; > to just > static struct dev_pm_ops xenbus_pm_ops = { > .freeze = xenbus_dev_freeze, > .thaw = xenbus_dev_thaw, > .restore = xenbus_dev_restore, > }; > > then the answer is no, AFAICS, from the code in drivers/base/power/main.c > (pm_op function).Looking at pm_op it doesn''t appear to be an error to not implement one or more hooks. For example we currently don''t implement freeze/thaw and that is currently ok because we don''t initiate that sort of suspend. Currently drivers/xen/manage.c hangs the suspend code off CONFIG_PM_SLEEP, I wonder if it shouldn''t be CONFIG_SUSPEND already and become CONFIG_HIBERNATE with your change? I also wonder if shutdown_handler shouldn''t check it is actually going to be able to perform the suspend _before_ acknowledging the suspend request, but that is outside the scope of this patch. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel