On Sat, Nov 19, 2022 at 09:36:15AM +0000, manish.mishra wrote: > Current logic assumes that channel connections on the destination side are > always established in the same order as the source and the first one will > always be the main channel followed by the multifid or post-copy > preemption channel. This may not be always true, as even if a channel has a > connection established on the source side it can be in the pending state on > the destination side and a newer connection can be established first. > Basically causing out of order mapping of channels on the destination side. > Currently, all channels except post-copy preempt send a magic number, this > patch uses that magic number to decide the type of channel. This logic is > applicable only for precopy(multifd) live migration, as mentioned, the > post-copy preempt channel does not send any magic number. Also, tls live > migrations already does tls handshake before creating other channels, so > this issue is not possible with tls, hence this logic is avoided for tls > live migrations. This patch uses read peek to check the magic number of > channels so that current data/control stream management remains > un-effected. > > Suggested-by: Daniel P. Berrangé <berra...@redhat.com > Signed-off-by: manish.mishra <manish.mis...@nutanix.com>
Acked-by: Peter Xu <pet...@redhat.com> -- Peter Xu
