Re: [PATCH v1] migration: fail the cap check if it requires the use of deferred incoming

[Peter Xu]

On Fri, May 19, 2023 at 02:34:57AM +0000, Wang, Wei W wrote:
> On Friday, May 19, 2023 3:20 AM, Peter Xu wrote:
> > On Fri, May 19, 2023 at 12:00:26AM +0800, Wei Wang wrote:
> > > qemu_start_incoming_migration needs to check the number of multifd
> > > channels or postcopy ram channels to configure the backlog parameter (i.e.
> > > the maximum length to which the queue of pending connections for
> > > sockfd may grow) of listen(). So multifd and postcopy-preempt caps
> > > require the use of deferred incoming, that is, calling
> > > qemu_start_incoming_migration should be deferred via qmp or hmp
> > > commands after the cap of multifd and postcopy-preempt are configured.
> > >
> > > Check if deferred incoming is used when enabling multifd or
> > > postcopy-preempt, and fail the check with error messages if not.
> > >
> > > Signed-off-by: Wei Wang <wei.w.wang@intel.com>
> > 
> > IIUC this will unfortunately break things like:
> > 
> >   -global migration.x-postcopy-preempt=on
> > 
> > where the cap is actually applied before incoming starts even with !defer so
> > it should still work.
> 
> Actually the patch doesn’t check "!defer". It just checks if incoming has 
> been started
> or not. It allows the 2 caps to be set only before incoming starts. So I 
> think the above
> should work.

Ah yes indeed it keeps working, because we apply -global bits before setup
sockets. Then it's fine by me since that's the only thing I would still
like to keep it working. :)

If so, can we reword the error message a bit?  Obviously as you said we're
not really checking against -defer, but established channels.  The problem
is if something is established without knowing multifd being there it may
not work for multifd or preempt, not strictly about defer.

How about:

  "Multifd/Preempt-Mode cannot be modified if incoming channel has setup"

?

-- 
Peter Xu