On 03/24/2016 11:24 PM, Ian Jackson wrote:
Changlong Xie writes ("[PATCH v12 14/26] primary vm suspend/resume/checkpoint
code"):
From: Wen Congyang <we...@cn.fujitsu.com>
...
Thanks. Most of this seems plausible (although I have done a review
of rather limited depth):
However, there are several instances like this:
+out:
+ libxl__ao_complete(egc, ao, ERROR_FAIL);
+}
libxl__ao_complete must not be called by some internal function in
this way. Only the same layer within libxl that called AO_CREATE is
allowed to call libxl__ao_complete.
Errors should be propagated by having the _setup function make the
callback with the appropriate error code. Eventually, the error will
propagate out (possibly via a series of callbacks and error handling
paths) to the same layer as called AO_CREATE.
See remus_setup_done and remus_setup_failed for examples.
You also need to make sure that when the setup fails, appropriate
teardown is done. In the remus case this includes invoking
libxl__checkpoint_devices_teardown, and chaining through to a second
callback.
I'm COLO is consistent with REMUS if setup failed, below is the
invocation path.
libxl__colo_save_setup
libxl__checkpoint_devices_setup(failed)
all_devices_setup_cb
libxl__multidev_one_callback
remus_setup_done
libxl__checkpoint_devices_teardown
remus_failover_cb
Thanks
-Xie
Thanks,
Ian.
.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
