[Top][All Lists]

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

Re: [PATCH] qmp: Stabilize preconfig

From: Paolo Bonzini
Subject: Re: [PATCH] qmp: Stabilize preconfig
Date: Mon, 15 Nov 2021 13:37:33 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0

On 11/13/21 08:52, Markus Armbruster wrote:
I'm not asking what to do "if it hurts", or "if you want a cold-plugged
device".  I'm asking whether there's a reason for ever wanting hot plug
instead of cold plug.  Or in other words, what can hot plug possibly
gain us over cold plug?

As far as I know, the answer is "nothing but trouble".

Yes, I agree.

If that's true, then what we should tell users is to stick to -device
for initial configuration, and stay away from device_add.

Yes, which is one issue with stabilizing -preconfig. It's not clear what exactly it is solving.

The boat for this has sailed.  The only sane way to do this is a new binary.

"Ideally" still applies to any new binary.

Well, "ideally" any new binary would only have a few command line
options, and ordering would be mostly irrelevant.  For example I'd
expect a QMP binary to only have a few options, mostly for
debugging/development (-L, -trace) and for process-wide settings (such
as -name).

This is where we disagree.  For me, a new, alternative qemu-system-FOO binary
should be able to replace the warty one we have.

One important kind of user is management applications.  Libvirt
developers tell us that they'd like to configure as much as possible via
QMP.  Another kind of user dear to me is me^H^Hdevelopers.  For ad hoc
testing, having to configure via QMP is a pain we'd rathe do without.  I
don't want to remain stuck on the traditional binary, I want to do this
with the new one.

Why do you care? For another example, you can use "reboot" or "systemctl isolate reboot.target" and they end up doing the same thing.

As long as qemu_init invokes qmp_machine_set, qmp_accel_set, qmp_device_add, qmp_plugin_add, qmp_cont, etc. to do its job, the difference between qemu-system-* and qemu-qmp-* is a couple thousands lines of boring code that all but disappears once the VM is up and running. IOW, with the right design (e.g. shortcut options for QOM properties good; dozens of global variables bad), there's absolutely no issue with some people using qemu-system-* and some using qemu-qmp-*.

Likewise, we'd fail QMP commands that are "out of phase".
@allow-preconfig is a crutch that only exists because we're afraid (with
reason) of hidden assumptions in QMP commands.

At this point, it's not even like that anymore (except for block devices
because my patches haven't been applied).

My point is that we still have quite a few commands without
'allow-preconfig' mostly because we are afraid of allowing them in
preconfig state, not because of true phase dependencies.

I think there's very few of them, if any (outside the block layer for
which patches exist), and those are due to distraction more than fear.

qapi/*.json has 216 commands, of which 26 carry 'allow-preconfig'.

Well, https://lists.gnu.org/archive/html/qemu-devel/2021-06/msg01597.html alone would more than double that. :)

Places like machine.json, machine-target.json, migration.json, replay.json have a lot of commands that are, obviously, almost entirely not suitable for preconfig. I don't think there are many commands left, I'd guess maybe 30 (meaning that ~60% are done).


reply via email to

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