[Top][All Lists]

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

Re: [PATCH] qmp: Stabilize preconfig

From: Damien Hedde
Subject: Re: [PATCH] qmp: Stabilize preconfig
Date: Wed, 10 Nov 2021 14:23:09 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.2

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.


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.


reply via email to

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