[PATCH] Use freeze/thaw/restore PM events for Guest suspend/resume/checkpoint

[PATCH] Use freeze/thaw/restore PM events for Guest suspend/resume/checkpoint

[Shriram Rajagopalan]

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;

Re: [PATCH] Use freeze/thaw/restore PM events for Guest suspend/resume/checkpoint

[Shriram Rajagopalan]

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.

Re: [PATCH] Use freeze/thaw/restore PM events for Guest suspend/resume/checkpoint

[Ian Campbell]

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.

Re: [PATCH] Use freeze/thaw/restore PM events for Guest suspend/resume/checkpoint

[Shriram Rajagopalan]

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

Re: [PATCH] Use freeze/thaw/restore PM events for Guest suspend/resume/checkpoint

[Ian Campbell]

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).

> ok

You 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.