Re: [PATCH 29/29] vl: allow -incoming defer with -preconfig

[Paolo Bonzini]

On 20/11/20 17:28, Igor Mammedov wrote:
> On Tue, 27 Oct 2020 14:21:44 -0400
> Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> > Now that there is no RUN_STATE_PRECONFIG anymore that can conflict with
> > RUN_STATE_INMIGRATE, we can allow -incoming defer with -preconfig.
> >
> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> > ---
> >   softmmu/vl.c | 5 ++---
> >   1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/softmmu/vl.c b/softmmu/vl.c
> > index 98666c0612..b0cb539da9 100644
> > --- a/softmmu/vl.c
> > +++ b/softmmu/vl.c
> > @@ -3199,9 +3199,8 @@ static void qemu_validate_options(void)
> >                        "mutually exclusive");
> >           exit(EXIT_FAILURE);
> >       }
> > -    if (incoming && preconfig_requested) {
> > -        error_report("'preconfig' and 'incoming' options are "
> > -                     "mutually exclusive");
> > +    if (incoming && preconfig_requested && strcmp(incoming, "defer") != 0) {
> why limit it only to 'defer'?

After these patches, the difference between "-incoming defer" and 
"-incoming foo" is very small: the latter adds an automatic 
"migrate-incoming foo" at the tail of x-exit-preconfig, and that's it.

At the time I sent these patches, my plan was to replace 
x-exit-preconfig with a command "finish-machine-init" that the user 
would follow with one of "cont", "migrate-incoming" or "loadvm".  So it 
would make sense to have "-incoming defer" only, because without 
"x-exit-preconfig" there's no command that triggers incoming migration 
as specified with "-incoming foo".

Then I sent only the minimal (so to speak) beginning of the series, but 
decided to be consrvative in what to allow on the command line.  Since 
you are interacting with the monitor anyway to exit preconfig, you can 
use it to send the migrate-incoming command.

Thanks,

Paolo