libxc: support to resume uncooperative HVM guests

libxc: support to resume uncooperative HVM guests

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 path (fast=0)
     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 path
     PV:       Unchanged.
     PVHVM:    Call XEN_DOMCTL_resumedomain to resume the guest. Because we
               don't modify the return code, PV drivers 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 (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 registers,
device state etc). In this case, we cannot use the fast path to resume it.
Keep the return code 0, and use the slow path to resume the guest.

Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
Signed-off-by: Yang Hongyang <hongyang.yang@easystack.cn>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
[ wei: reformat commit message a bit ]
Signed-off-by: Wei Liu <wei.liu2@citrix.com>