Re: [PATCH] qmp: Stabilize preconfig

[Paolo Bonzini]

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).

Paolo