On 10/25/21 2:19 PM, 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.
I see a difference between the two. -preconfig starts QEMU in such a way
that its configuration can still be changed (in my particular use case
vCPUs can be assigned to NUMA nodes), while -S does not allow that. If
we had one state for both, then some commands must be forbidden from
executing as soon as 'cont' is issued. Moreover, those commands would
need to do much more than they are doing now (e.g. regenerate ACPI table
after each run). Subsequently, validating configuration would need to be
postponed until the first 'cont' because with just one state QEMU can't
know when the last config command was issued.