On 11/3/21 9:02 AM, Markus Armbruster wrote: > Daniel P. Berrangé <berra...@redhat.com> writes: > >> On Mon, Nov 01, 2021 at 03:37:58PM +0100, Michal Prívozník wrote: >>> On 10/25/21 2:19 PM, Markus Armbruster wrote: >>>> 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. >>> >>> 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. > > Doesn't all this apply to x-exit-preconfig already? > > * Some commands are only allowed before x-exit-preconfig, > e.g. set-numa-node. > > * The complete (pre-)configuration is only available at > x-exit-preconfig. In particular, ACPI tables can be fixed only then.
So why was preconfig introduced in the first place? I mean, from libvirt's POV it doesn't really matter whether it needs to use both -preconfig and -S or just -S (or some new -option). But ideally, we would start QEMU with nothing but monitor config and then pass whole configuration via the monitor. I thought it would be simpler for QEMU if it had three states. Michal
