Re: [PATCH] qmp: Stabilize preconfig

[Damien Hedde <damien.hedde@greensocs.com>]

On 11/10/21 13:54, Michal Prívozník wrote:
> On 11/3/21 9:02 AM, Markus Armbruster wrote:
>> Daniel P. Berrangé <berrange@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 <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.
>>
>> 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
> 
> 

IMHO only introducing preconfig allowed to pause qemu at an early-enough 
stage to do qemu configuration. '-S' was just way too late.

We can hope being able, some day, to start with only preconfig and 
monitor setup and do all the rest using the monitor. AFAIK, right now 
accelerator, machine and device options cannot be configured on the 
monitor even with preconfig. For the devices it should be doable soon.

Damien