From: Wei Liu <wei.liu2@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Changlong Xie <xiecl.fnst@cn.fujitsu.com>,
Wei Liu <wei.liu2@citrix.com>,
Wen Congyang <wency@cn.fujitsu.com>,
Ian Jackson <Ian.Jackson@eu.citrix.com>,
Yang Hongyang <hongyang.yang@easystack.cn>
Subject: [PATCH 1/2] libxc: support to resume uncooperative HVM guests
Date: Thu, 31 Mar 2016 16:59:27 +0100 [thread overview]
Message-ID: <1459439968-22150-2-git-send-email-wei.liu2@citrix.com> (raw)
In-Reply-To: <1459439968-22150-1-git-send-email-wei.liu2@citrix.com>
From: Wen Congyang <wency@cn.fujitsu.com>
Before this patch:
1. Suspend
a. PVHVM and PV: we use the same way to suspend the guest (send the
suspend request to the guest). If the guest doesn't support evtchn, the
xenstore variant will be used, suspending the guest via XenBus control
node.
b. Pure HVM: we call xc_domain_shutdown(..., SHUTDOWN_suspend) to suspend
the guest.
2. Resume:
a. Fast path (fast=1)
Do not change the guest state. We call libxl__domain_resume(.., 1) which
calls xc_domain_resume(..., 1 /* fast=1*/) to resume the guest.
PV: Modify the return code to 1, and than call the domctl:
XEN_DOMCTL_resumedomain
PVHVM: same with PV
Pure HVM: Do nothing in modify_returncode, and than call the domctl:
XEN_DOMCTL_resumedomain
b. Slow path (fast=0)
Used when the guest's state have been changed. Will call
libxl__domain_resume(..., 0) to resume the guest.
PV: Update start info, and reset all secondary CPU states. Than call
the domctl: XEN_DOMCTL_resumedomain
PVHVM: Can not be resumed. You will get the following error message:
"Cannot resume uncooperative HVM guests"
Pure HVM: Same with PVHVM
After this patch:
1. Suspend
Unchanged.
2. Resume
a. Fast path
Unchanged.
b. Slow path
PV: Unchanged.
PVHVM: Call XEN_DOMCTL_resumedomain to resume the guest. Because we
don't modify the return code, PV drivers will disconnect
and reconnect.
The guest ends up doing the XENMAPSPACE_shared_info
XENMEM_add_to_physmap hypercall and resetting all of its CPU
states to point to the shared_info (except the ones past 32).
That is the Linux kernel does that - regardless whether the
SCHEDOP_shutdown:SHUTDOWN_suspend returns 1 or not.
Pure HVM: Call XEN_DOMCTL_resumedomain to resume the guest.
Under COLO, we will update the guest's state (modify memory, CPU registers,
device state etc). In this case, we cannot use the fast path to resume it.
Keep the return code 0, and use the slow path to resume the guest.
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
Signed-off-by: Yang Hongyang <hongyang.yang@easystack.cn>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
[ wei: reformat commit message a bit ]
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
tools/libxc/xc_resume.c | 25 +++++++++++++++++++++----
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/tools/libxc/xc_resume.c b/tools/libxc/xc_resume.c
index 5bf4cf0..6bf7d9c 100644
--- a/tools/libxc/xc_resume.c
+++ b/tools/libxc/xc_resume.c
@@ -109,6 +109,26 @@ static int xc_domain_resume_cooperative(xc_interface *xch, uint32_t domid)
return do_domctl(xch, &domctl);
}
+static int xc_domain_resume_hvm(xc_interface *xch, uint32_t domid)
+{
+ DECLARE_DOMCTL;
+
+ /*
+ * The domctl XEN_DOMCTL_resumedomain unpause each vcpu. After
+ * the domctl, the guest will run.
+ *
+ * If it is PVHVM, the guest called the hypercall
+ * SCHEDOP_shutdown:SHUTDOWN_suspend
+ * to suspend itself. We don't modify the return code, so the PV driver
+ * will disconnect and reconnect.
+ *
+ * If it is a HVM, the guest will continue running.
+ */
+ domctl.cmd = XEN_DOMCTL_resumedomain;
+ domctl.domain = domid;
+ return do_domctl(xch, &domctl);
+}
+
static int xc_domain_resume_any(xc_interface *xch, uint32_t domid)
{
DECLARE_DOMCTL;
@@ -138,10 +158,7 @@ static int xc_domain_resume_any(xc_interface *xch, uint32_t domid)
*/
#if defined(__i386__) || defined(__x86_64__)
if ( info.hvm )
- {
- ERROR("Cannot resume uncooperative HVM guests");
- return rc;
- }
+ return xc_domain_resume_hvm(xch, domid);
if ( xc_domain_get_guest_width(xch, domid, &dinfo->guest_width) != 0 )
{
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-03-31 16:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-31 15:59 [PATCH 0/2] Remaining prerequisite patches for COLO Wei Liu
2016-03-31 15:59 ` Wei Liu [this message]
2016-04-01 15:59 ` [PATCH 1/2] libxc: support to resume uncooperative HVM guests Olaf Hering
2016-04-01 16:10 ` Wei Liu
2016-04-01 16:42 ` Olaf Hering
2016-04-01 19:41 ` Olaf Hering
2016-03-31 15:59 ` [PATCH 2/2] libxc: Document xc_domain_resume Wei Liu
2016-04-01 13:45 ` [PATCH 0/2] Remaining prerequisite patches for COLO Ian Jackson
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=1459439968-22150-2-git-send-email-wei.liu2@citrix.com \
--to=wei.liu2@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=hongyang.yang@easystack.cn \
--cc=wency@cn.fujitsu.com \
--cc=xen-devel@lists.xenproject.org \
--cc=xiecl.fnst@cn.fujitsu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).