On Tue, Dec 13, 2022 at 04:38:47PM -0500, Peter Xu wrote: > From: "manish.mishra" <manish.mis...@nutanix.com> > > 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. > > Reviewed-by: Peter Xu <pet...@redhat.com> > Reviewed-by: Daniel P. Berrang?? <berra...@redhat.co > Suggested-by: Daniel P. Berrang?? <berra...@redhat.com
Again, both name and email address termination is mangled. With 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 :|
