From: "Daniel P. Berrangé" <berrange@redhat.com>
To: cenjiahui <cenjiahui@huawei.com>
Cc: quintela@redhat.com, qemu-devel@nongnu.org, zhouyibo3@huawei.com,
dgilbert@redhat.com, peterx@redhat.com, fangying1@huawei.com
Subject: Re: [PATCH 3/3] migration/multifd: fix potential wrong acception order of IOChannel
Date: Thu, 24 Oct 2019 10:52:27 +0100 [thread overview]
Message-ID: <20191024095227.GC3700@redhat.com> (raw)
In-Reply-To: <20191023033214.31592-3-cenjiahui@huawei.com>
On Wed, Oct 23, 2019 at 11:32:14AM +0800, cenjiahui wrote:
> From: Jiahui Cen <cenjiahui@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.
> Signed-off-by: Jiahui Cen <cenjiahui@huawei.com>
> Signed-off-by: Ying Fang <fangying1@huawei.com>
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2019-10-24 10:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20191023033214.31592-1-cenjiahui@huawei.com>
2019-10-23 3:32 ` [PATCH 3/3] migration/multifd: fix potential wrong acception order of IOChannel cenjiahui
2019-10-24 9:52 ` Daniel P. Berrangé [this message]
2019-10-24 13:53 ` cenjiahui
2019-10-24 14:34 ` Daniel P. Berrangé
2019-10-25 6:55 ` Jiahui Cen
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=20191024095227.GC3700@redhat.com \
--to=berrange@redhat.com \
--cc=cenjiahui@huawei.com \
--cc=dgilbert@redhat.com \
--cc=fangying1@huawei.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=zhouyibo3@huawei.com \
/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.