[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] qmp: Stabilize preconfig

From: Michal Prívozník
Subject: Re: [PATCH] qmp: Stabilize preconfig
Date: Wed, 10 Nov 2021 13:54:57 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]