From: Juan Quintela <quintela@redhat.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 6/9] migration: create new section to store global state
Date: Wed, 17 Jun 2015 03:10:57 +0200 [thread overview]
Message-ID: <87eglbgmvy.fsf@neno.neno> (raw)
In-Reply-To: <20150518102329.GD2201@work-vm> (David Alan Gilbert's message of "Mon, 18 May 2015 11:23:30 +0100")
"Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
> * Juan Quintela (quintela@redhat.com) wrote:
>> This includes a new section that for now just stores the current qemu state.
>>
>> Right now, there are only one way to control what is the state of the
>> target after migration.
>>
>> - If you run the target qemu with -S, it would start stopped.
>> - If you run the target qemu without -S, it would run just after migration finishes.
>>
>> The problem here is what happens if we start the target without -S and
>> there happens one error during migration that puts current state as
>> -EIO. Migration would ends (notice that the error happend doing block
>> IO, network IO, i.e. nothing related with migration), and when
>> migration finish, we would just "continue" running on destination,
>> probably hanging the guest/corruption data, whatever.
>>
>> Signed-off-by: Juan Quintela <quintela@redhat.com>
>> +
>> +typedef struct {
>> + int32_t size;
>> + uint8_t runstate[100];
>> +} GlobalState;
>
> unsigned for size? Could use something smaller than a int32_t
> I guess for a 100 byte buffer.
uint8_t
>
>> +
>> +static GlobalState global_state;
>> +
>> +void global_state_store(void)
>> +{
>> + if (runstate_store((char *)global_state.runstate,
>> + sizeof(global_state.runstate)) == -1) {
>> + error_report("Runstate is too big: %s\n", global_state.runstate);
>
> error_report's don't need the \n
done.
>
>> + exit(-1);
>> + }
>> +}
>> +
>> +char *global_state_get_runstate(void)
>> +{
>> + return (char *)global_state.runstate;
>> +}
>
> Is that needed outside of this file - if not then just make
> it static or use the data directly?
>
State was born on vl.c, then I noticed that I could put it here, and
forgot to remove globals. Don.
>> +
>> +static int global_state_post_load(void *opaque, int version_id)
>> +{
>> + GlobalState *s = opaque;
>> + int ret = 0;
>> + char *runstate = (char *)s->runstate;
>> +
>> + if (strcmp(runstate, "running") != 0) {
>> +
>> + RunState r = runstate_index(runstate);
>> +
>> + if (r == -1) {
>> + error_report("Unknown received state %s\n", runstate);
>
> error_report's don't need the \n
>
>> + return -1;
>> + }
>> + ret = vm_stop_force_state(r);
>
> Why do this here, rather than in process_incoming_migration_co;
> that would seem neater to keep the state change in one place.
If state is unknown for destination here, migration can still be aborted
at this point, later that is not possible. Not possible in the sense
that source would not noticed that destination has exited because it
didn't understood something.
But we could move that to incoming, just not clear that it is going to
be easier, because then we have to do error control at a point that
don't have it right now.
Later, Juan.
>
> Dave
>
>> + }
>> +
>> + return ret;
>> +}
>> +
>> +static void global_state_pre_save(void *opaque)
>> +{
>> + GlobalState *s = opaque;
>> +
>> + s->size = strlen((char *)s->runstate) + 1;
>> +}
>> +
>> +static const VMStateDescription vmstate_globalstate = {
>> + .name = "globalstate",
>> + .version_id = 1,
>> + .minimum_version_id = 1,
>> + .post_load = global_state_post_load,
>> + .pre_save = global_state_pre_save,
>> + .fields = (VMStateField[]) {
>> + VMSTATE_INT32(size, GlobalState),
>> + VMSTATE_BUFFER(runstate, GlobalState),
>> + VMSTATE_END_OF_LIST()
>> + },
>> +};
>> +
>> +void register_global_state(void)
>> +{
>> + /* We would use it independently that we receive it */
>> + strcpy((char *)&global_state.runstate, "");
>> + vmstate_register(NULL, 0, &vmstate_globalstate, &global_state);
>> +}
>> diff --git a/vl.c b/vl.c
>> index b8844f6..8af6c79 100644
>> --- a/vl.c
>> +++ b/vl.c
>> @@ -4387,6 +4387,7 @@ int main(int argc, char **argv, char **envp)
>> return 0;
>> }
>>
>> + register_global_state();
>> if (incoming) {
>> Error *local_err = NULL;
>> qemu_start_incoming_migration(incoming, &local_err);
>> --
>> 2.4.0
>>
>>
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2015-06-17 1:11 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-14 16:28 [Qemu-devel] [PATCH 0/9] Optional toplevel sections Juan Quintela
2015-05-14 16:28 ` [Qemu-devel] [PATCH 1/9] migration: create savevm_state Juan Quintela
2015-05-18 9:15 ` Dr. David Alan Gilbert
2015-05-14 16:28 ` [Qemu-devel] [PATCH 2/9] migration: Use normal VMStateDescriptions for Subsections Juan Quintela
2015-05-18 9:54 ` Dr. David Alan Gilbert
2015-05-14 16:28 ` [Qemu-devel] [PATCH 3/9] runstate: Add runstate store Juan Quintela
2015-05-18 10:35 ` Dr. David Alan Gilbert
2015-06-17 0:28 ` Juan Quintela
2015-05-18 10:38 ` Denis V. Lunev
2015-05-18 14:50 ` Eric Blake
2015-06-17 0:55 ` Juan Quintela
2015-05-14 16:28 ` [Qemu-devel] [PATCH 4/9] runstate: create runstate_index function Juan Quintela
2015-05-18 9:58 ` Dr. David Alan Gilbert
2015-05-18 14:55 ` Eric Blake
2015-06-17 0:31 ` Juan Quintela
2015-06-17 0:55 ` Juan Quintela
2015-05-14 16:28 ` [Qemu-devel] [PATCH 5/9] runstate: migration allows more transitions now Juan Quintela
2015-05-14 16:28 ` [Qemu-devel] [PATCH 6/9] migration: create new section to store global state Juan Quintela
2015-05-18 10:23 ` Dr. David Alan Gilbert
2015-06-17 1:10 ` Juan Quintela [this message]
2015-05-14 16:28 ` [Qemu-devel] [PATCH 7/9] global_state: Make section optional Juan Quintela
2015-05-18 11:03 ` Dr. David Alan Gilbert
2015-06-17 1:25 ` Juan Quintela
2015-05-14 16:28 ` [Qemu-devel] [PATCH 8/9] vmstate: Create optional sections Juan Quintela
2015-05-18 11:23 ` Dr. David Alan Gilbert
2015-05-19 9:17 ` Dr. David Alan Gilbert
2015-05-14 16:28 ` [Qemu-devel] [PATCH 9/9] migration: Add configuration section Juan Quintela
2015-05-18 11:39 ` Dr. David Alan Gilbert
2015-06-17 1:39 ` Juan Quintela
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87eglbgmvy.fsf@neno.neno \
--to=quintela@redhat.com \
--cc=dgilbert@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.