Re: [PATCH v2 COLOPre 02/13] tools/libxc: support to resume uncooperative HVM guests

[Ian Campbell <ian.campbell@citrix.com>]

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 <wency@cn.fujitsu.com>
> >>>>
> >>>> 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.