Re: [PATCH v2 3/3] migration: Postpone postcopy preempt channel to be after main

[Peter Xu]

On Wed, Feb 08, 2023 at 08:22:05PM +0100, Juan Quintela wrote:
> Peter Xu <peterx@redhat.com> wrote:
> > Postcopy with preempt-mode enabled needs two channels to communicate.  The
> > order of channel establishment is not guaranteed.  It can happen that the
> > dest QEMU got the preempt channel connection request before the main
> > channel is established, then the migration may make no progress even during
> > precopy due to the wrong order.
> >
> > To fix it, create the preempt channel only if we know the main channel is
> > established.
> >
> > For a general postcopy migration, we delay it until postcopy_start(),
> > that's where we already went through some part of precopy on the main
> > channel.  To make sure dest QEMU has already established the channel, we
> > wait until we got the first PONG received.  That's something we do at the
> > start of precopy when postcopy enabled so it's guaranteed to happen sooner
> > or later.
> >
> > For a postcopy recovery, we delay it to qemu_savevm_state_resume_prepare()
> > where we'll have round trips of data on bitmap synchronizations, which
> > means the main channel must have been established.
> >
> > Signed-off-by: Peter Xu <peterx@redhat.com>
> 
> Reviewed-by: Juan Quintela <quintela@redhat.com>
> 
> But I still think that our channel setup is overcomplex (famous last
> words, specially thinking that I designed it, sniff).

:)

I think it's more of my fault, when not noticing I have had a chance to add
at least a channel handshake for the new preempt ones, knowing that the
migration handshake never being there.

It'll be even better if that'll be provided by QIOChannel, or some higher
level abstraction layer so we can have named QIO channels that
automatically pair each other for two QEMU instances.

I'll take away the R-b, thanks.

-- 
Peter Xu