On 2019/10/24 17:52, Daniel P. Berrangé wrote:
> On Wed, Oct 23, 2019 at 11:32:14AM +0800, cenjiahui wrote:
>> From: Jiahui Cen <cenjia...@huawei.com>
>>
>> Multifd assumes the migration thread IOChannel is always established before
>> the multifd IOChannels, but this assumption will be broken in many situations
>> like network packet loss.
>>
>> For example:
>> Step1: Source (migration thread IOChannel)  --SYN-->  Destination
>> Step2: Source (migration thread IOChannel)  <--SYNACK  Destination
>> Step3: Source (migration thread IOChannel, lost) --ACK-->X  Destination
>> Step4: Source (multifd IOChannel) --SYN-->    Destination
>> Step5: Source (multifd IOChannel) <--SYNACK   Destination
>> Step6: Source (multifd IOChannel, ESTABLISHED) --ACK-->  Destination
>> Step7: Destination accepts multifd IOChannel
>> Step8: Source (migration thread IOChannel, ESTABLISHED) -ACK,DATA->  
>> Destination
>> Step9: Destination accepts migration thread IOChannel
>>
>> The above situation can be reproduced by creating a weak network environment,
>> such as "tc qdisc add dev eth0 root netem loss 50%". The wrong acception 
>> order
>> will cause magic check failure and thus lead to migration failure.
>>
>> This patch fixes this issue by sending a migration IOChannel initial packet 
>> with
>> a unique id when using multifd migration. Since the multifd IOChannels will 
>> also
>> send initial packets, the destination can judge whether the processing 
>> IOChannel
>> belongs to multifd by checking the id in the initial packet. This mechanism 
>> can
>> ensure that different IOChannels will go to correct branches in our test.
> 
> Isn't this going to break back compatibility when new QEMU talks to old
> QEMU with multifd enabled ? New QEMU will be sending a packet that old
> QEMU isn't expecting IIUC.

Yes, it actually breaks back compatibility. But since the old QEMU has bug with
multifd, it may be not suitable to use multifd to migrate from new QEMU to old
QEMU in my opinion.

Hi, Quintela, how do you think about this ?

> 
>> Signed-off-by: Jiahui Cen <cenjia...@huawei.com>
>> Signed-off-by: Ying Fang <fangyi...@huawei.com>

Regards,
Jiahui Cen


Reply via email to