From patchwork Thu Feb 18 02:43:15 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Wen Congyang X-Patchwork-Id: 8345171 Return-Path: X-Original-To: patchwork-xen-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id BDE1E9FC82 for ; Thu, 18 Feb 2016 02:46:10 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id E6467203A5 for ; Thu, 18 Feb 2016 02:46:09 +0000 (UTC) Received: from lists.xen.org (lists.xenproject.org [50.57.142.19]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id ED268203F1 for ; Thu, 18 Feb 2016 02:46:08 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aWEYh-0007v2-0c; Thu, 18 Feb 2016 02:43:11 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aWEYe-0007tp-C7 for xen-devel@lists.xen.org; Thu, 18 Feb 2016 02:43:08 +0000 Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id 1A/B3-09478-BBF25C65; Thu, 18 Feb 2016 02:43:07 +0000 X-Env-Sender: wency@cn.fujitsu.com X-Msg-Ref: server-10.tower-206.messagelabs.com!1455763384!23157191!1 X-Originating-IP: [59.151.112.132] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 7.35.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 48767 invoked from network); 18 Feb 2016 02:43:06 -0000 Received: from cn.fujitsu.com (HELO heian.cn.fujitsu.com) (59.151.112.132) by server-10.tower-206.messagelabs.com with SMTP; 18 Feb 2016 02:43:06 -0000 X-IronPort-AV: E=Sophos;i="5.20,346,1444665600"; d="scan'208";a="3658303" Received: from unknown (HELO cn.fujitsu.com) ([10.167.33.5]) by heian.cn.fujitsu.com with ESMTP; 18 Feb 2016 10:42:44 +0800 Received: from G08CNEXCHPEKD01.g08.fujitsu.local (unknown [10.167.33.80]) by cn.fujitsu.com (Postfix) with ESMTP id B877042AC844; Thu, 18 Feb 2016 10:41:04 +0800 (CST) Received: from G08FNSTD140052.g08.fujitsu.local (10.167.226.52) by G08CNEXCHPEKD01.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 18 Feb 2016 10:42:42 +0800 From: Wen Congyang To: xen devel , Konrad Rzeszutek Wilk , Andrew Cooper , Ian Campbell , Ian Jackson , Wei Liu Date: Thu, 18 Feb 2016 10:43:15 +0800 Message-ID: <1455763403-18641-6-git-send-email-wency@cn.fujitsu.com> X-Mailer: git-send-email 2.5.0 In-Reply-To: <1455763403-18641-1-git-send-email-wency@cn.fujitsu.com> References: <1455763403-18641-1-git-send-email-wency@cn.fujitsu.com> MIME-Version: 1.0 X-Originating-IP: [10.167.226.52] X-yoursite-MailScanner-ID: B877042AC844.A7873 X-yoursite-MailScanner: Found to be clean X-yoursite-MailScanner-From: wency@cn.fujitsu.com X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 Cc: Lars Kurth , Changlong Xie , Wen Congyang , Gui Jianfeng , Jiang Yunhong , Dong Eddie , Shriram Rajagopalan , Yang Hongyang Subject: [Xen-devel] [PATCH v8 05/13] tools/libxc: support to resume uncooperative HVM guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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 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 PV: unchanged PVHVM: call XEN_DOMCTL_resumedomain to resume the guest. Because we don't modify the return code, the PV driver 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(well 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's registers, device status...). In this case, we cannot use the fast path to resume it. Keep the return code 0, and use a slow path to resume the guest. While resuming HVM using slow path is not supported currently, this patch is to make the resume call to not fail. Signed-off-by: Wen Congyang Signed-off-by: Yang Hongyang Reviewed-by: Konrad Rzeszutek Wilk --- 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 e692b81..4eedf87 100644 --- a/tools/libxc/xc_resume.c +++ b/tools/libxc/xc_resume.c @@ -108,6 +108,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; @@ -137,10 +157,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 ) {