mirror of
https://github.com/xen-project/xen.git
synced 2026-10-28 10:11:27 +01:00
Ian Jackson
c04c825bdf
As Ian Campbell writes in http://bugs.xenproject.org/xen/bug/30: There are two mechanisms by which a suspend can be aborted and the original domain resumed. The older method is that the toolstack resets a bunch of state (see tools/python/xen/xend/XendDomainInfo.py resumeDomain) and then restarts the domain. The domain will see HYPERVISOR_suspend return 0 and will continue without any realisation that it is actually running in the original domain and not in a new one. This method is supposed to be implemented by libxl_domain_resume(suspend_cancel=0) but it is not. The other method is newer and in this case the toolstack arranges that HYPERVISOR_suspend returns SUSPEND_CANCEL and restarts it. The domain will observe this and realise that it has been restarted in the same domain and will behave accordingly. This method is implemented, correctly AFAIK, by libxl_domain_resume(suspend_cancel=1). Attempting to use the old method without doing all of the work simply causes the guest to crash. Implementing the work required for old method, or for checking that domains actually support the new method, is not feasible at this stage of the 4.4 release. So, always use the new method, without regard to the declarations of support by the guest. This is a strict improvement: guests which do in fact support the new method will work, whereas ones which don't are no worse off. There are two call sites of libxl_domain_resume that need fixing, both in the migration error path. With this change I observe a correct and successful resumption of a Debian wheezy guest with a Linux 3.4.70 kernel after a migration attempt which I arranged to fail by nobbling the block hotplug script. Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <Ian.Campbell@citrix.com> CC: konrad.wilk@oracle.com CC: David Vrabel <david.vrabel@citrix.com> CC: Boris Ostrovsky <boris.ostrovsky@oracle.com>