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 10:41:35 +0100 Message-ID: <1434015695.30003.139.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> <1434012289.30003.120.camel@citrix.com> <55794D21.9080409@cn.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55794D21.9080409@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, ian.jackson@eu.citrix.com, yunhong.jiang@intel.com, eddie.dong@intel.com, xen-devel@lists.xen.org, guijianfeng@cn.fujitsu.com, andrew.cooper3@citrix.com, rshriram@cs.ubc.ca, Yang Hongyang List-Id: xen-devel@lists.xenproject.org On Thu, 2015-06-11 at 16:56 +0800, Wen Congyang wrote: > On 06/11/2015 04:44 PM, Ian Campbell wrote: > > 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 remember it now. IIRC, the behavior in the guest are the same. Is it right? I _think_ so, but I don't know for sure, you'd have to check.