Re: [PATCH] qmp: Stabilize preconfig

[Markus Armbruster]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 11/12/21 12:48, Markus Armbruster wrote:
>>> The monitor starts, the question is the availability of the event loop.
>> 
>> What does the event loop depend on?
>
> It depends on moving the relevant code out of qemu_init (at least 
> conditionally, as is the case for what is in qmp_x_exit_preconfig). 
> This in turn has the problem that it's ugly to have lingering unapplied 
> settings from the command line.
>
>>>>> 5) PHASE_MACHINE_READY - machine init done notifiers have been called
>>>>> and the VM is ready.  Devices plugged in this phase already count as
>>>>> hot-plugged.  -S starts the monitor here.
>> 
>> Why would anyone *want* to plug a device in PHASE_MACHINE_READY (when
>> the plug is hot) instead of earlier (when it's cold)?
>
> Well, PHASE_MACHINE_READY includes the whole time the guest is running. 
>   So the simplest thing to do is to tell the user "if it hurts, don't do 
> it".  If you want a cold-plugged device, plug it during 
> PHASE_MACHINE_INIT, which right now means on the command line.

One, we don't tell users anything of the sort as far as I can tell, and
two, I'm afraid you missed my question :)

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

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

Such advice would rain on the "configure everything with QMP" parade.
No big deal, we already know that parade needs plenty of work before it
can hit main street, and having to provide a way to cold plug with QMP
is merely yet another sub-task.

>>>> Related question: when exactly in these phases do we create devices
>>>> specified with -device?
>>>
>>> In PHASE_MACHINE_INIT---that is, after the machine has been initialized
>>> and before machine-done-notifiers have been called.
>> 
>> In other words, you should never use device_add where -device would do,
>> because the latter gives you cold plug (which is simple and reliable),
>> and the former hot plug (which is the opposite).
>
> Exactly.
>
>>> No, because the monitor goes directly from a point where device_add 
>>> fails (PHASE_ACCEL_CREATED) to a point where devices are hotplugged 
>>> (PHASE_MACHINE_READY).
>> 
>> Bummer.
>
> True, but consider that these "phases" were reconstructed ex post.  It's 
> not like x-exit-preconfig was designed to skip PHASE_MACHINE_INIT; it's 
> just that preconfig used to call qemu_main_loop() at the point which is 
> now known as PHASE_ACCEL_CREATED.

Understand.  I'm just trying to map the terrain so we can hopefully get
from here to a better place.


[...]

>>>> The earlier the monitor becomes available, the better.
>>>> Ideally, we'd process the command line strictly left to right, and fail
>>>> options that are "out of phase".  Make the monitor available right when
>>>> we process its -mon.  The -chardev for its character device must precede
>>>> it.
>>>
>>> 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.  A
combination of configuration file(s), CLI and HMP is much quicker.  I
don't want to remain stuck on the traditional binary, I want to do this
with the new one.

Catering to this kind of users should not be hard.  All it takes is a
sensiblly designed startup.  Rough sketch without much thought:

1. Start event loop

2. Feed it CLI left to right.  Each option runs a handler just like each
   QMP command does.

   Options that read a configuration file inject the file into the feed.

   Options that create a monitor create it suspended.

   Options may advance the phase / run state, and they may require
   certain phase(s).

3. When we're done with CLI, resume any monitors we created.

4. Monitors now feed commands to the event loop.  Commands may advance
   the phase / run state, and they may require certain phase(s).

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