Jumping in at v12 for a bit of QAPI review (and whatever else catched my eye nearby), please pardon my ignorance of COLO in general, and previous review of this series in particular.
zhanghailiang <zhang.zhanghaili...@huawei.com> writes: > We need communications protocol of user-defined to control the checkpoint > process. > > The new checkpoint request is started by Primary VM, and the interactive > process > like below: > Checkpoint synchronizing points, > > Primary Secondary > initial work > 'checkpoint-ready' <------------------------------ @ > > 'checkpoint-request' @ -----------------------------> > Suspend (Only in > hybrid mode) > 'checkpoint-reply' <------------------------------ @ > Suspend&Save state > 'vmstate-send' @ -----------------------------> > Send state Receive state > 'vmstate-received' <------------------------------ @ > Release packets Load state > 'vmstate-load' <------------------------------ @ > Resume Resume (Only in hybrid > mode) Long lines. Easy to fix: shorten your arrows. > Start Comparing (Only in hybrid mode) > NOTE: > 1) '@' who sends the message > 2) Every sync-point is synchronized by two sides with only > one handshake(single direction) for low-latency. > If more strict synchronization is required, a opposite direction > sync-point should be added. > 3) Since sync-points are single direction, the remote side may > go forward a lot when this side just receives the sync-point. > 4) For now, we only support 'periodic' checkpoint, for which > the Secondary VM is not running, later we will support 'hybrid' mode. Useful commit message, but shouldn't this explanation (also) be in the source? > Signed-off-by: zhanghailiang <zhang.zhanghaili...@huawei.com> > Signed-off-by: Li Zhijian <lizhij...@cn.fujitsu.com> > Signed-off-by: Gonglei <arei.gong...@huawei.com> > Cc: Eric Blake <ebl...@redhat.com> > --- > v12: > - Rename colo_ctl_put() to colo_put_cmd() > - Rename colo_ctl_get() to colo_get_check_cmd() and drop > the third parameter > - Rename colo_ctl_get_cmd() to colo_get_cmd() > - Remove useless 'invalid' member for COLOcommand enum. > v11: > - Add missing 'checkpoint-ready' communication in comment. > - Use parameter to return 'value' for colo_ctl_get() (Dave's suggestion) > - Fix trace for colo_ctl_get() to trace command and value both > v10: > - Rename enum COLOCmd to COLOCommand (Eric's suggestion). > - Remove unused 'ram-steal' > > Signed-off-by: zhanghailiang <zhang.zhanghaili...@huawei.com> > --- > migration/colo.c | 183 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++- > qapi-schema.json | 25 ++++++++ > trace-events | 2 + > 3 files changed, 208 insertions(+), 2 deletions(-) > > diff --git a/migration/colo.c b/migration/colo.c > index 0ab9618..0ce2a6e 100644 > --- a/migration/colo.c > +++ b/migration/colo.c > @@ -10,10 +10,12 @@ > * later. See the COPYING file in the top-level directory. > */ > > +#include <unistd.h> > #include "sysemu/sysemu.h" > #include "migration/colo.h" > #include "trace.h" > #include "qemu/error-report.h" > +#include "qemu/sockets.h" > > bool colo_supported(void) > { > @@ -34,6 +36,100 @@ bool migration_incoming_in_colo_state(void) > return mis && (mis->state == MIGRATION_STATUS_COLO); > } > > +static int colo_put_cmd(QEMUFile *f, uint32_t cmd) > +{ > + int ret; > + > + if (cmd >= COLO_COMMAND_MAX) { Needs a trivial rebase due to commit 7fb1cf1. > + error_report("%s: Invalid cmd", __func__); > + return -EINVAL; Can this run in a context with different error handling needs? Or asked differently: who may ultimately handle this error? Whoever that may be, how does it need to report errors? Peeking ahead: the immediate callers don't handle this error, they just pass it on their callers. I'm asking because I'm trying to understand whether error_report() is appropriate here, or whether you need to use error_setg(), and leave the actual reporting to the spot that ultimately handles this error. > + } > + qemu_put_be32(f, cmd); > + qemu_fflush(f); > + > + ret = qemu_file_get_error(f); > + trace_colo_put_cmd(COLOCommand_lookup[cmd]); > + > + return ret; > +} Looks like @cmd is a COLOCommand. Why is the parameter type uint32_t? > + > +static int colo_get_cmd(QEMUFile *f, uint32_t *cmd) > +{ > + int ret; > + > + *cmd = qemu_get_be32(f); > + ret = qemu_file_get_error(f); > + if (ret < 0) { > + return ret; > + } > + if (*cmd >= COLO_COMMAND_MAX) { > + error_report("%s: Invalid cmd", __func__); > + return -EINVAL; > + } > + trace_colo_get_cmd(COLOCommand_lookup[*cmd]); > + return 0; > +} Same question. The "get" in the name suggests the function returns the value gotten, like similarly named function elsewhere in migration/ do. > + > +static int colo_get_check_cmd(QEMUFile *f, uint32_t expect_cmd) > +{ > + int ret; > + uint32_t cmd; > + > + ret = colo_get_cmd(f, &cmd); > + if (ret < 0) { > + return ret; > + } > + if (cmd != expect_cmd) { > + error_report("Unexpect colo command, expect:%d, but got cmd:%d", Grammar nit: "Unexpected". Suggest: "Unexpected COLO command %d, expected %d". > + expect_cmd, cmd); > + return -EINVAL; > + } > + > + return 0; > +} > + > +static int colo_do_checkpoint_transaction(MigrationState *s) > +{ > + int ret; > + > + ret = colo_put_cmd(s->to_dst_file, COLO_COMMAND_CHECKPOINT_REQUEST); > + if (ret < 0) { > + goto out; > + } > + > + ret = colo_get_check_cmd(s->rp_state.from_dst_file, > + COLO_COMMAND_CHECKPOINT_REPLY); > + if (ret < 0) { > + goto out; > + } > + > + /* TODO: suspend and save vm state to colo buffer */ > + > + ret = colo_put_cmd(s->to_dst_file, COLO_COMMAND_VMSTATE_SEND); > + if (ret < 0) { > + goto out; > + } > + > + /* TODO: send vmstate to Secondary */ > + > + ret = colo_get_check_cmd(s->rp_state.from_dst_file, > + COLO_COMMAND_VMSTATE_RECEIVED); > + if (ret < 0) { > + goto out; > + } > + > + ret = colo_get_check_cmd(s->rp_state.from_dst_file, > + COLO_COMMAND_VMSTATE_LOADED); > + if (ret < 0) { > + goto out; > + } > + > + /* TODO: resume Primary */ > + > +out: > + return ret; > +} > + > static void colo_process_checkpoint(MigrationState *s) > { > int ret = 0; > @@ -45,12 +141,28 @@ static void colo_process_checkpoint(MigrationState *s) > goto out; > } > > + /* > + * Wait for Secondary finish loading vm states and enter COLO > + * restore. > + */ > + ret = colo_get_check_cmd(s->rp_state.from_dst_file, > + COLO_COMMAND_CHECKPOINT_READY); > + if (ret < 0) { > + goto out; > + } > + > qemu_mutex_lock_iothread(); > vm_start(); > qemu_mutex_unlock_iothread(); > trace_colo_vm_state_change("stop", "run"); > > - /*TODO: COLO checkpoint savevm loop*/ > + while (s->state == MIGRATION_STATUS_COLO) { > + /* start a colo checkpoint */ > + ret = colo_do_checkpoint_transaction(s); > + if (ret < 0) { > + goto out; > + } > + } > > out: > if (ret < 0) { > @@ -73,6 +185,31 @@ void migrate_start_colo_process(MigrationState *s) > qemu_mutex_lock_iothread(); > } > > +/* > + * return: > + * 0: start a checkpoint > + * -1: some error happened, exit colo restore > + */ Suggest to make this a proper function comment, i.e. /* * One line describing purpose * As many additional lines as it takes to further explain what it does, * preconditions, side effects, return values, error conditions. Use * @name to refer to parameters. */ > +static int colo_wait_handle_cmd(QEMUFile *f, int *checkpoint_request) > +{ > + int ret; > + uint32_t cmd; > + > + ret = colo_get_cmd(f, &cmd); > + if (ret < 0) { > + /* do failover ? */ > + return ret; > + } > + > + switch (cmd) { > + case COLO_COMMAND_CHECKPOINT_REQUEST: > + *checkpoint_request = 1; > + return 0; > + default: > + return -EINVAL; > + } switch makes sense only if you're going to add cases. Suggest to set *checkpoint_request = 0 on error, for robustness. > +} > + > void *colo_process_incoming_thread(void *opaque) > { > MigrationIncomingState *mis = opaque; > @@ -93,7 +230,49 @@ void *colo_process_incoming_thread(void *opaque) > */ > qemu_set_block(qemu_get_fd(mis->from_src_file)); > > - /* TODO: COLO checkpoint restore loop */ > + > + ret = colo_put_cmd(mis->to_src_file, COLO_COMMAND_CHECKPOINT_READY); > + if (ret < 0) { > + goto out; > + } > + > + while (mis->state == MIGRATION_STATUS_COLO) { > + int request = 0; Dead initialization. > + int ret = colo_wait_handle_cmd(mis->from_src_file, &request); > + > + if (ret < 0) { > + break; > + } else { > + if (!request) { > + continue; > + } > + } Convoluted nesting. Suggest if (ret < 0) { break; } if (!request) { continue; } Actually, !request can't happen, so I'd make it. if (ret < 0) { break; } assert(request); until it can happen. > + /* FIXME: This is unnecessary for periodic checkpoint mode */ When you add a FIXME, you should probably point to it in your commit message. May not be necessary when the FIXME goes away later in this series. Pretty much the same for TODO. > + ret = colo_put_cmd(mis->to_src_file, COLO_COMMAND_CHECKPOINT_REPLY); > + if (ret < 0) { > + goto out; Above, you used break to "break" the loop on error. Here, you use "goto out". Suggest to pick one and stick to it. > + } > + > + ret = colo_get_check_cmd(mis->from_src_file, > + COLO_COMMAND_VMSTATE_SEND); > + if (ret < 0) { > + goto out; > + } > + > + /* TODO: read migration data into colo buffer */ > + > + ret = colo_put_cmd(mis->to_src_file, COLO_COMMAND_VMSTATE_RECEIVED); > + if (ret < 0) { > + goto out; > + } > + > + /* TODO: load vm state */ > + > + ret = colo_put_cmd(mis->to_src_file, COLO_COMMAND_VMSTATE_LOADED); > + if (ret < 0) { > + goto out; > + } > + } > > out: > if (ret < 0) { > diff --git a/qapi-schema.json b/qapi-schema.json > index c9ff34e..85f7800 100644 > --- a/qapi-schema.json > +++ b/qapi-schema.json > @@ -720,6 +720,31 @@ > { 'command': 'migrate-start-postcopy' } > > ## > +# @COLOCommand > +# > +# The commands for COLO fault tolerance > +# > +# @checkpoint-ready: SVM is ready for checkpointing > +# > +# @checkpoint-request: PVM tells SVM to prepare for new checkpointing > +# > +# @checkpoint-reply: SVM gets PVM's checkpoint request > +# > +# @vmstate-send: VM's state will be sent by PVM. > +# > +# @vmstate-size: The total size of VMstate. > +# > +# @vmstate-received: VM's state has been received by SVM. > +# > +# @vmstate-loaded: VM's state has been loaded by SVM. > +# > +# Since: 2.6 > +## > +{ 'enum': 'COLOCommand', > + 'data': [ 'checkpoint-ready', 'checkpoint-request', 'checkpoint-reply', > + 'vmstate-send', 'vmstate-size','vmstate-received', > + 'vmstate-loaded' ] } > + Space after 'vmstate-size', please. 'vmstate-size' is not used in this patch. You may want to add it with its first use instead. Should this enum really be named "COLOCommand"? 'checkpoint-ready', 'checkpoint-request', 'vmstate-send' look like commands to me, but the others look like replies. > # @MouseInfo: > # > # Information about a mouse device. > diff --git a/trace-events b/trace-events > index 5565e79..39fdd8d 100644 > --- a/trace-events > +++ b/trace-events > @@ -1579,6 +1579,8 @@ postcopy_ram_incoming_cleanup_join(void) "" > > # migration/colo.c > colo_vm_state_change(const char *old, const char *new) "Change '%s' => '%s'" > +colo_put_cmd(const char *msg) "Send '%s' cmd" > +colo_get_cmd(const char *msg) "Receive '%s' cmd" > > # kvm-all.c > kvm_ioctl(int type, void *arg) "type 0x%x, arg %p" I like how this commit creates just the two state machines, and leaves filling in their actions to later commits. Helps ignorant rewiewers like me :)