Re: MultiFD and default channel out of order mapping on receive side.

[Peter Xu <peterx@redhat.com>]

On Thu, Oct 20, 2022 at 08:14:19PM +0530, manish.mishra wrote:
> I had one concern, during recover we do not send any magic. As of now we
  do not support multifd with postcopy so it should be fine, we can do
  explict checking for non-recovery case. But i remember from some
  discussion in future there may be support for multiFD with postcopy or
  have multiple postcopy preempt channels too, then proper handshake will
  be required? So at some point we want to take that path? For now i agree
  approach 1 will be good as suggested by Daniel it can be backported
  easily to older qemu's too.

Yes for the long run I think we should provide a generic solution for all
the channels to be established for migration purpose.

Not to mention that as I replied previously to my original email, the trick
won't easily work with dest QEMU where we need further change to allow qemu
to accept new channels during loading of the VM.

Considering the complexity that it'll take just to resolve the prempt
channel ordering, I think maybe it's cleaner we just look for the long term
goal.

-- 
Peter Xu