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

[Wen Congyang <wency@xxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxx>
>>
>> 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
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 <wency@xxxxxxxxxxxxxx>
>> Signed-off-by: Yang Hongyang <yanghy@xxxxxxxxxxxxxx>
>> ---
>>  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 )
>>      {
> 
> 
> .
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel