Michal Privoznik <mpriv...@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 <mpriv...@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. Details in the sub-thread Message-ID: <87zi21apkh....@dusky.pond.sub.org> https://lists.gnu.org/archive/html/qemu-devel/2018-04/msg02447.html My conclusion was My gut's reaction to preconfig is as nauseous as ever. It adds complexity we wouldn't want or need with sanely structured program startup. It might still be the best we can do, and something we need to do. You have to take on technical debt sometimes. To know for sure this is the case here, we'd have to explore alternatives more seriously. Like repaying some of the existing technical debt around there. Sadly, I lack the time to take on such a project. Since I lack the money to put where my mouth is, I'm going to shut up and get out of your way. Message-ID: <87tvqx12no....@dusky.pond.sub.org> https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg05584.html However, we made it experimental: commit 361ac948a5c960ce7a093cec1744bff0d5af3dec Author: Markus Armbruster <arm...@redhat.com> Date: Thu Jul 5 11:14:02 2018 +0200 cli qmp: Mark --preconfig, exit-preconfig experimental Committing to the current --preconfig / exit-preconfig interface before it has seen any use is premature. Mark both as experimental, the former in documentation, the latter by renaming it to x-exit-preconfig. See the previous commit for more detailed rationale. Signed-off-by: Markus Armbruster <arm...@redhat.com> Message-Id: <20180705091402.26244-3-arm...@redhat.com> Reviewed-by: Eric Blake <ebl...@redhat.com> Acked-by: Eduardo Habkost <ehabk...@redhat.com> Acked-by: Igor Mammedov <imamm...@redhat.com> [Straightforward conflict with commit 514337c142f resolved] commit 1f214ee1b83afd10fd5e1b63f4ecc03f9a8115c4 Author: Markus Armbruster <arm...@redhat.com> Date: Thu Jul 5 11:14:01 2018 +0200 qapi: Do not expose "allow-preconfig" in query-qmp-schema According to commit 047f7038f58, option --preconfig [...] allows pausing QEMU in the new RUN_STATE_PRECONFIG state, allowing the configuration of QEMU from QMP before the machine jumps into board initialization code of machine_run_board_init() The intent is to allow management to query machine state and additionally configure it using previous query results within one QEMU instance (i.e. eliminate the need to start QEMU twice, 1st to query board specific parameters and 2nd for actual VM start using query results for additional parameters). 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. Sadly, some commands expect initialization to be complete. Running them in --preconfig's main loop violates their preconditions. Since we don't really know which commands are safe, we use a whitelist. This drags the concept of run state into the QMP core. The whitelist is done as a command flag in the QAPI schema (commit d6fe3d02e9a). Drags the concept of run state further into the QAPI language. The command flag is exposed in query-qmp-schema (also commit d6fe3d02e9a). This makes it ABI. I consider the whole thing an offensively ugly hack, but sometimes an ugly hack is the best we can do to solve a problem people have. The need described by the commit message quote above is genuine. The proper solution would be a main loop that permits complete configuration via QMP. This is out of reach, thus the hack. However, even though the need is genuine, it isn't urgent: libvirt is not going to use this anytime soon. Baking a hack into ABI before it has any users is a bad idea. This commit reverts the parts of commit d6fe3d02e9a that affect ABI via query-qmp-schema. The commit did the following: (1) Add command flag 'allow-preconfig' to the QAPI schema language (2) Pass it to code generators (3) Have the commands.py code generator pass it to the command registry (so commit 047f7038f58 can use it as whitelist) (4) Add 'allow-preconfig' to SchemaInfoCommand (neglecting to update qapi-code-gen.txt section "Client JSON Protocol introspection") (5) Set 'allow-preconfig': true for commands qmp_capabilities, query-commands, query-command-line-options, query-status Revert exactly (4), plus a bit of documentation added to qemu-tech.info in commit 047f7038f58. Shrinks query-qmp-schema's output from 126.5KiB to 121.8KiB for me. Signed-off-by: Markus Armbruster <arm...@redhat.com> Message-Id: <20180705091402.26244-2-arm...@redhat.com> Reviewed-by: Eric Blake <ebl...@redhat.com> Acked-by: Eduardo Habkost <ehabk...@redhat.com> Acked-by: Igor Mammedov <imamm...@redhat.com> [Straightforward conflict with commit d626b6c1ae7 resolved] 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?