From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49418) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBGx1-0002Wp-1A for qemu-devel@nongnu.org; Tue, 22 Dec 2015 02:01:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBGww-0007mX-T3 for qemu-devel@nongnu.org; Tue, 22 Dec 2015 02:01:38 -0500 Received: from szxga02-in.huawei.com ([119.145.14.65]:11463) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBGwv-0007m0-Pj for qemu-devel@nongnu.org; Tue, 22 Dec 2015 02:01:34 -0500 References: <1450167779-9960-1-git-send-email-zhang.zhanghailiang@huawei.com> <1450167779-9960-11-git-send-email-zhang.zhanghailiang@huawei.com> <87d1u2u8co.fsf@blackfin.pond.sub.org> From: Hailiang Zhang Message-ID: <5678F51E.8000002@huawei.com> Date: Tue, 22 Dec 2015 15:00:46 +0800 MIME-Version: 1.0 In-Reply-To: <87d1u2u8co.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH COLO-Frame v12 10/38] COLO: Implement colo checkpoint protocol List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: lizhijian@cn.fujitsu.com, quintela@redhat.com, yunhong.jiang@intel.com, eddie.dong@intel.com, qemu-devel@nongnu.org, peter.huangpeng@huawei.com, arei.gonglei@huawei.com, stefanha@redhat.com, amit.shah@redhat.com, dgilbert@redhat.com, hongyang.yang@easystack.cn Hi Markus, On 2015/12/19 16:54, Markus Armbruster wrote: > 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. > Thanks all the same :) > zhanghailiang 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) OK. >> 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 >> Signed-off-by: Li Zhijian >> Signed-off-by: Gonglei >> Cc: Eric Blake >> --- >> 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 >> --- >> 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 >> #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. > Hmm, i know what you mean, we handled them all together after exit from the colo process loop, Use error_setg() seems to be a good idea, with this modification, we can also drop the return value. I will fix it in next version. >> + } >> + 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? > OK, i will change it to use enum COLOCommand. >> + >> +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. > Do you mean it should return the cmd value directly, not though parameter way ? After we convert it to use error_setg() to indicate success or not, we can do like that. I will fix it. >> + >> +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". > Will fix it. >> + 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. > Good catch, i will fix it as your suggestion. > /* > * 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. > Yes, we will add COLO_COMMAND_GUEST_SHUTDOWN in the later patch, and maybe all more cases in future. > Suggest to set *checkpoint_request = 0 on error, for robustness. > OK. >> +} >> + >> 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. > Yes, you are right, it should never 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. > OK, i will move it to the corresponding patch. > Should this enum really be named "COLOCommand"? 'checkpoint-ready', > 'checkpoint-request', 'vmstate-send' look like commands to me, but the > others look like replies. > Yes, COLOCommand is not so exact. what about name it COLOProtocol? > >> # @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 :) > > Do you mean i should split this patch ? Leave this patch with the simplest colo process, maybe just 'ready, request, reply', and add the other states in later patch? Thanks, Hailiang > . >