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

[Hailiang Zhang <zhang.zhanghailiang@huawei.com>]

On 2016/10/27 11:57, Amit Shah wrote:
> 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 <zhang.zhanghailiang@huawei.com>
>>>> Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com>
>>>> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
>>>
>>> Reviewed-by: Amit Shah <amit.shah@redhat.com>
>>>
>>>> @@ -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.
>

OK, i will add this in next version, thanks.

>
> 		Amit
>
> .
>