Re: [PATCH] qmp: Stabilize preconfig

[Paolo Bonzini]

On 25/10/21 14:19, Markus Armbruster wrote:
> Michal Privoznik <mprivozn@redhat.com> writes:
>
> > The -preconfig option and exit-preconfig command are around for
> > quite some time now. However, they are still marked as unstable.
> > This is suboptimal because it may block some upper layer in
> > consuming it. In this specific case - Libvirt avoids using
> > experimental features.
> >
> > Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
>
> If I remember correctly, the motivation for -preconfig was NUMA
> configuration via QMP.  More uses may have appeared since.
>
> Back then, I questioned the need for yet another option and yet another
> state: why not -S?
>
> The answer boiled down to
>
> 0. Yes, having just one would be a simpler and cleaner interface, but
>
> 1. the godawful mess QEMU startup has become makes -S unsuitable for
>     some things we want to do, so we need -preconfig,
>
> 2. which is in turn unsuitable for other things we want to do, so we
>     still need -S".
>
> 3. Cleaning up the mess to the point where "simpler and cleaner" becomes
>     viable again is not in the cards right now.

Some things have changed since then:

* The preconfig implementation is much, much better than it used to be. 
 There's no preconfig runstate anymore and QEMU effectively always 
starts in preconfig mode; it simply invokes x-exit-preconfig if 
preconfig is not specified.  This also made it sensible to add a lot 
make more commands to allow_preconfig.

* On the other hand, preconfig still does not support all machine 
initialization, and especially it does not support device-add (so 
libvirt could not, for example, remove all of its 
-blockdev/-netdev/-device code in favor of QMP).  And -machine supports 
compound options (albeit not JSON yet; see commit d8fb7d0969, "vl: 
switch -M parsing to keyval", 2021-07-06) which those could be used for 
NUMA.  This makes preconfig mode much less interesting compared to a 
QMP-only QEMU executable.

If we decide that preconfig is the way to go, I would still not 
stabilize it in its current form, and would do a couple aesthetic 
adjustments before: 1) make loadvm, cont and migrate-incoming exit 
preconfig, 2) add a new command finish-machine-init be the equivalent of 
"exit preconfig and stay paused", 3) make -S implicit if -preconfig is 
specified.

As an aside, I agree with the original decision not to expose 
allow-preconfig in query-qmp-schema.  Originally only a couple commands 
were exposed in preconfig mode; these days, a command should simply be 
allowed in preconfig mode if it makes sense, and the only ones that are 
missing are block device commands[1].  That patch should be a 
precondition for stabilizing preconfig.

>     The implementation is a bit of a hack: it splices in an additional
>     main loop before machine creation, in special runstate preconfig.  New
>     command exit-preconfig exits that main loop.  QEMU continues
>     initializing, creates the machine, and runs the good old main loop.
>     The replacement of the main loop is transparent to monitors.

Quite an understatement. :)

> Before we make it a stable interface, we should ponder:
>
> * Is cleaning up the mess to the point where "simpler and cleaner"
>    becomes viable again still impractical?
>
> * If yes, what are the chances of it becoming practical?

To sum up: it's been cleaned up, and preconfig has benefited from it. 
The question is whether to keep cleaning up (and then the obvious 
direction is the QMP-only QEMU executable), or decide that we've gotten 
to the point of diminishing returns.

Paolo

[1] https://patchew.org/QEMU/20210511153949.506200-1-pbonzini@redhat.com/