[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v4 16/47] Return path: Source handling of return
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [Qemu-devel] [PATCH v4 16/47] Return path: Source handling of return path |
Date: |
Thu, 23 Oct 2014 19:00:42 +0100 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
* Paolo Bonzini (address@hidden) wrote:
> Il 03/10/2014 19:47, Dr. David Alan Gilbert (git) ha scritto:
> > +/* Source side RP state */
> > +struct MigrationRetPathState {
> > + uint32_t latest_ack;
> > + QemuThread rp_thread;
> > + bool error;
>
> Should the QemuFile be in here?
Yes, done.
> > +};
> > +
>
> Also please do not abbrev words, and add a typedef that matches the
> struct if it is useful. If it is not, just embed the struct without
> giving the type a name (struct { } rp_state).
Done.
>
> > +static bool migration_already_active(MigrationState *ms)
> > +{
> > + switch (ms->state) {
> > + case MIG_STATE_ACTIVE:
> > + case MIG_STATE_SETUP:
> > + return true;
> > +
> > + default:
> > + return false;
> > +
> > + }
> > +}
>
> Should CANCELLING also be considered active? It is on the source->dest
> path.
Hmm, possibly - but my intention here was just to round up all of the
places that already checked for ACTIVE+SETUP so that I could add
POSTCOPY_ACTIVE;
only one of those places also checked for CANCELLING, so I left it out.
> > +static void await_outgoing_return_path_close(MigrationState *ms)
> > +{
> > + /*
> > + * If this is a normal exit then the destination will send a SHUT and
> > the
> > + * rp_thread will exit, however if there's an error we need to cause
> > + * it to exit, which we can do by a shutdown.
> > + * (canceling must also shutdown to stop us getting stuck here if
> > + * the destination died at just the wrong place)
> > + */
> > + if (qemu_file_get_error(ms->file) && ms->return_path) {
> > + qemu_file_shutdown(ms->return_path);
> > + }
>
> As mentioned early, I think it's simpler to let these function handle
> themselves the case where there is no return path, and call them
> unconditionally.
I still need to think about that.
Dave
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK
- [Qemu-devel] [PATCH v4 10/47] Return path: Open a return path on QEMUFile for sockets, (continued)
- [Qemu-devel] [PATCH v4 10/47] Return path: Open a return path on QEMUFile for sockets, Dr. David Alan Gilbert (git), 2014/10/03
- [Qemu-devel] [PATCH v4 12/47] Handle bi-directional communication for fd migration, Dr. David Alan Gilbert (git), 2014/10/03
- [Qemu-devel] [PATCH v4 11/47] Return path: socket_writev_buffer: Block even on non-blocking fd's, Dr. David Alan Gilbert (git), 2014/10/03
- [Qemu-devel] [PATCH v4 13/47] Migration commands, Dr. David Alan Gilbert (git), 2014/10/03
- [Qemu-devel] [PATCH v4 14/47] Return path: Control commands, Dr. David Alan Gilbert (git), 2014/10/03
- [Qemu-devel] [PATCH v4 16/47] Return path: Source handling of return path, Dr. David Alan Gilbert (git), 2014/10/03
- Re: [Qemu-devel] [PATCH v4 16/47] Return path: Source handling of return path, zhanghailiang, 2014/10/16
[Qemu-devel] [PATCH v4 15/47] Return path: Send responses from destination to source, Dr. David Alan Gilbert (git), 2014/10/03
[Qemu-devel] [PATCH v4 17/47] qemu_loadvm errors and debug, Dr. David Alan Gilbert (git), 2014/10/03
[Qemu-devel] [PATCH v4 18/47] ram_debug_dump_bitmap: Dump a migration bitmap as text, Dr. David Alan Gilbert (git), 2014/10/03
[Qemu-devel] [PATCH v4 19/47] Rework loadvm path for subloops, Dr. David Alan Gilbert (git), 2014/10/03