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

[Peter Xu <peterx@redhat.com>]

On Tue, May 23, 2023 at 01:44:03AM +0000, Wang, Wei W wrote:
> On Tuesday, May 23, 2023 7:36 AM, Peter Xu wrote:
> > > > We may also want to trap the channel setups on num:
> > > >
> > > > migrate_params_test_apply():
> > > >
> > > >     if (params->has_multifd_channels) {
> > > >         dest->multifd_channels = params->multifd_channels;
> > > >     }
> > >
> > > Didn’t get this one. What do you want to add to above?
> > 
> > I meant after listen() is called with an explicit number in this case, should we
> > disallow changing of multifd number of channels?
> 
> Got you, thanks. That seems unnecessary to me, as the cap setting is required
> for the use of multifd and patching there already achieves below what we want:
> - users get the error message when deferred -incoming isn’t used;
> - fail the cap setting for multifd, meaning that multifd won't be used (i.e.
> no place that will care about multifd_channels).

It's about whether we want to protect e.g. below steps:

1. start dest qemu with -incoming defer
2. "migrate-set-capabilities" to enable multifd
3. "migrate-incoming xxx" to setup the sockets
4. "migrate-set-parameters" to setup the num of multifd   <--- will be invalid here

Would that still be a problem that falls into the same category of what
this patch wants to protect qemu from?

Thanks,

-- 
Peter Xu