From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH v2 COLOPre 02/13] tools/libxc: support to resume uncooperative HVM guests Date: Thu, 11 Jun 2015 09:44:49 +0100 Message-ID: <1434012289.30003.120.camel@citrix.com> References: <1433734997-26570-1-git-send-email-yanghy@cn.fujitsu.com> <1433734997-26570-3-git-send-email-yanghy@cn.fujitsu.com> <1433949533.30003.99.camel@citrix.com> <5578F59F.5000307@cn.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5578F59F.5000307@cn.fujitsu.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wen Congyang Cc: wei.liu2@citrix.com, eddie.dong@intel.com, andrew.cooper3@citrix.com, yunhong.jiang@intel.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, guijianfeng@cn.fujitsu.com, rshriram@cs.ubc.ca, Yang Hongyang List-Id: xen-devel@lists.xenproject.org On Thu, 2015-06-11 at 10:42 +0800, Wen Congyang wrote: > On 06/10/2015 11:18 PM, Ian Campbell wrote: > > On Mon, 2015-06-08 at 11:43 +0800, Yang Hongyang wrote: > >> From: Wen Congyang > >> > >> For PVHVM, the hypercall return code is 0, and it can be resumed > >> in a new domain context. > >> we suspend PVHVM and resume it is like this: > >> 1. suspend it via evtchn > >> 2. modifty the return code to 1 > >> 3. the guest know that the suspend is cancelled, we will use fast path > >> to resume it. > >> > >> 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. We have > >> updated the guest state, so we call it a new domain context. > >> > >> For HVM, the hypercall is a NOP. > > > > This doesn't match my reading of domain_resume on the Xen side, which is > > the ultimate effect of this hypercall. It seems to unpause the domain > > (and all vcpus) regardless of the domain type, including PVHVM vs HVM > > (which isn't something Xen is generally aware of anyway). > > > > I also can't really follow the stuff about PVHVM vs HVM vs uncooperative > > guests, and I certainly can't see where the PVHVM vs HVM distinction is > > made in this patch. > > Sorry for my mistake. I read the codes again: > > 1. suspend > a. PVHVM and PV: we use the same way to suspend the guest(send the suspend > request to the guest) > b. pure HVM: we call xc_domain_shutdown(..., SHUTDOWN_suspend) to suspend > the guest > c. ???: suspending the guest via XenBus control node AFAIK c is another option under a, it depends on whether the guest supports evtchn or not, if not then the xenstore variant will be used. > I don't know we will goto c in which case. > > 2. Resume: > a. fast path > In this case, we don't change the guest's state. > PV: modify the return code to 1, and than call the domctl: XEN_DOMCTL_resumedomain > PVHVM: same with PV > HVM: do nothing in modify_returncode, and than call the domctl: XEN_DOMCTL_resumedomain > b. slow > In this case, we have changed the guest's state. > PV: update start info, and reset all secondary CPU states. Than call the > domctl: XEN_DOMCTL_resumedomain > PVHVM and HVM can not be resumed. > > For PVHVM, in my test, only call the domctl: XEN_DOMCTL_resumedomain > can work. I am not sure if we should update start info and reset all secondary CPU > states. > > For pure HVM guest, in my test, only call the domctl: XEN_DOMCTL_resumedomain can > work. > > So we can call libxl__domain_resume(..., 1) if we don't change the guest state, otherwise > call libxl__domain_resume(..., 0). > > Any suggestion is welcomed. > > Thanks > Wen Congyang > > > > > > Ian. > > > > > >> > >> Signed-off-by: Wen Congyang > >> Signed-off-by: Yang Hongyang > >> --- > >> tools/libxc/xc_resume.c | 22 ++++++++++++++++++---- > >> 1 file changed, 18 insertions(+), 4 deletions(-) > >> > >> diff --git a/tools/libxc/xc_resume.c b/tools/libxc/xc_resume.c > >> index e67bebd..bd82334 100644 > >> --- a/tools/libxc/xc_resume.c > >> +++ b/tools/libxc/xc_resume.c > >> @@ -109,6 +109,23 @@ 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; > >> + > >> + /* > >> + * If it is PVHVM, the hypercall return code is 0, because this > >> + * is not a fast path resume, we do not modify_returncode as in > >> + * xc_domain_resume_cooperative. > >> + * (resuming it in a new domain context) > >> + * > >> + * If it is a HVM, the hypercall is a NOP. > >> + */ > >> + 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 +155,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 ) > >> { > > > > > > . > > >