Re: [Qemu-devel] [PATCH COLO-Frame (Base) v21 05/17] COLO: Establish a new communicating path for COLO

[Amit Shah]

On (Wed) 26 Oct 2016 [22:05:22], Hailiang Zhang wrote:
> On 2016/10/26 13:06, Amit Shah wrote:
> >On (Tue) 18 Oct 2016 [20:10:01], zhanghailiang wrote:
> >>This new communication path will be used for returning messages
> >>from Secondary side to Primary side.
> >>
> >>Signed-off-by: zhanghailiang <address@hidden>
> >>Signed-off-by: Li Zhijian <address@hidden>
> >>Reviewed-by: Dr. David Alan Gilbert <address@hidden>
> >
> >Reviewed-by: Amit Shah <address@hidden>
> >
> >>@@ -63,8 +75,24 @@ void *colo_process_incoming_thread(void *opaque)
> >>      migrate_set_state(&mis->state, MIGRATION_STATUS_ACTIVE,
> >>                        MIGRATION_STATUS_COLO);
> >>
> >>+    mis->to_src_file = qemu_file_get_return_path(mis->from_src_file);
> >>+    if (!mis->to_src_file) {
> >>+        error_report("COLO incoming thread: Open QEMUFile to_src_file 
> >>failed");
> >>+        goto out;
> >>+    }
> >>+    /*
> >>+     * Note: We set the fd to unblocked in migration incoming coroutine,
> >>+     * But here we are in the COLO incoming thread, so it is ok to set the
> >>+     * fd back to blocked.
> >>+     */
> >>+    qemu_file_set_blocking(mis->from_src_file, true);
> >
> >Why does it need to be blocking?
> >
> 
> Because, the communication/action between Primary side and Secondary side 
> should be
> sequential. Just as postcopy does. :)

Yea - I mean please include that in the comment too so it's obvious
why it's done.


                Amit