From: Alan Stern <stern@rowland.harvard.edu>
To: Ian Campbell <ijc@hellion.org.uk>
Cc: linux-pm@lists.linux-foundation.org,
xen-devel@lists.xensource.com, "SUZUKI,
Kazuhiro" <kaz@jp.fujitsu.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/2] Fix hangup after creating checkpoint on Xen.
Date: Tue, 8 Feb 2011 11:46:37 -0500 (EST) [thread overview]
Message-ID: <Pine.LNX.4.44L0.1102081143470.2100-100000__8735.351303085$1297183759$gmane$org@iolanthe.rowland.org> (raw)
In-Reply-To: <1297164178.9388.65.camel@zakaz.uk.xensource.com>
On Tue, 8 Feb 2011, Ian Campbell wrote:
> The problem is that currently we have:
>
> dpm_suspend_start(PMSG_SUSPEND);
>
> dpm_suspend_noirq(PMSG_SUSPEND);
>
> sysdev_suspend(PMSG_SUSPEND);
> /* suspend hypercall */
> sysdev_resume();
>
> dpm_resume_noirq(PMSG_RESUME);
>
> dpm_resume_end(PMSG_RESUME);
>
> However the suspend hypercall can return a value indicating that the
> suspend didn't actually happen (e.g. was cancelled). This is used e.g.
> when checkpointing guests, because in that case you want the original
> guest to continue. When the suspend didn't happen the drivers need to
> recover differently from if it did.
That is odd, and it is quite different from the intended design of the
PM core. Drivers are supposed to put their devices into a known
suspended state; then afterwards they put the devices back into an
operational state. What happens while the devices are in the suspended
state isn't supposed to matter -- the system transition can fail, but
devices get treated exactly the same way as if it succeeded.
Why do your drivers need to recover differently based on the success of
the hypercall?
Alan Stern
next prev parent reply other threads:[~2011-02-08 16:46 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-07 9:07 [PATCH 0/2] Fix hangup after creating checkpoint on Xen SUZUKI, Kazuhiro
2011-02-07 9:08 ` [PATCH 1/2] " SUZUKI, Kazuhiro
2011-02-07 9:08 ` SUZUKI, Kazuhiro
2011-02-07 9:08 ` [PATCH 2/2] " SUZUKI, Kazuhiro
2011-02-07 9:08 ` SUZUKI, Kazuhiro
2011-02-07 9:35 ` [PATCH 0/2] " Rafael J. Wysocki
2011-02-08 11:22 ` Ian Campbell
2011-02-08 11:22 ` Ian Campbell
2011-02-08 16:46 ` Alan Stern [this message]
2011-02-08 16:46 ` [linux-pm] " Alan Stern
2011-02-08 16:46 ` Alan Stern
2011-02-08 17:35 ` Ian Campbell
2011-02-08 17:35 ` Ian Campbell
2011-02-09 23:16 ` Brendan Cully
2011-02-09 23:16 ` Brendan Cully
2011-02-09 23:42 ` Alan Stern
2011-02-09 23:42 ` Alan Stern
2011-02-10 11:40 ` [Xen-devel] " Ian Campbell
2011-02-10 11:40 ` [Xen-devel] Re: [linux-pm] " Ian Campbell
2011-02-10 11:40 ` Ian Campbell
2011-02-10 16:00 ` [Xen-devel] " Alan Stern
2011-02-10 16:00 ` [Xen-devel] Re: [linux-pm] " Alan Stern
2011-02-10 16:00 ` Alan Stern
2011-02-10 16:26 ` [Xen-devel] " Rafael J. Wysocki
2011-02-10 16:26 ` Rafael J. Wysocki
2011-02-10 16:26 ` [Xen-devel] " Rafael J. Wysocki
2011-02-10 16:34 ` Ian Campbell
2011-02-10 16:34 ` [Xen-devel] Re: [linux-pm] " Ian Campbell
2011-02-10 16:34 ` Ian Campbell
2011-02-10 17:01 ` [Xen-devel] " Rafael J. Wysocki
2011-02-10 17:01 ` Rafael J. Wysocki
2011-02-17 7:56 ` [PATCH] update comments in pm.h describing Xen Guest save/restore/checkpoint use case Shriram Rajagopalan
2011-02-17 7:56 ` Shriram Rajagopalan
2011-02-17 10:56 ` [Xen-devel] " Ian Campbell
2011-02-17 10:56 ` Ian Campbell
2011-02-10 17:01 ` [Xen-devel] Re: [PATCH 0/2] Fix hangup after creating checkpoint on Xen Rafael J. Wysocki
2011-02-10 18:56 ` [Xen-devel] Re: [linux-pm] " Alan Stern
2011-02-10 18:56 ` Alan Stern
2011-02-10 18:56 ` [Xen-devel] " Alan Stern
2011-02-09 23:42 ` Alan Stern
2011-02-10 11:31 ` [Xen-devel] Re: [linux-pm] " Ian Campbell
2011-02-10 11:31 ` Ian Campbell
2011-02-10 12:40 ` Ian Campbell
2011-02-10 19:31 ` Brendan Cully
2011-02-11 9:14 ` Ian Campbell
2011-02-11 9:37 ` Pasi Kärkkäinen
2011-02-11 9:51 ` Ian Campbell
2011-02-11 18:13 ` Shriram Rajagopalan
2011-02-14 9:15 ` Ian Campbell
2011-02-14 9:27 ` Ian Campbell
2011-02-10 17:53 ` [Xen-devel] " Brendan Cully
2011-02-10 17:53 ` [Xen-devel] Re: [linux-pm] " Brendan Cully
2011-02-10 17:53 ` Brendan Cully
2011-02-10 11:31 ` [Xen-devel] " Ian Campbell
2011-02-09 23:16 ` Brendan Cully
2011-02-08 17:35 ` Ian Campbell
2011-02-08 11:22 ` Ian Campbell
2011-02-07 9:35 ` Rafael J. Wysocki
-- strict thread matches above, loose matches on Subject: below --
2011-02-07 9:07 SUZUKI, Kazuhiro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='Pine.LNX.4.44L0.1102081143470.2100-100000__8735.351303085$1297183759$gmane$org@iolanthe.rowland.org' \
--to=stern@rowland.harvard.edu \
--cc=ijc@hellion.org.uk \
--cc=kaz@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.