Re: [RFC PATCH v3 0/5] QMP support for cold-plugging devices

[Markus Armbruster]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Wed, Nov 24, 2021 at 02:50:11PM +0100, Markus Armbruster wrote:
>> Damien Hedde <damien.hedde@greensocs.com> writes:
>> 
>> > The biggest difference is the fw_cfg option I think: it is related
>> > with the rom_set_order_override()/rom_reset_order_override() (line 17
>> > and 25). There is also the usb devices parts in between. I lack the 
>> > knowledge about fw_cfg/usb to tell if it is important or not.
>> >
>> > What I wanted to say is I don't know if the difference is
>> > acceptable. If we want device_add to support all -device use cases, it
>> > is not. In that case we need to stop either in the middle of this
>> > function (line 15) or at the end (better with your sketch in mind).
>> >
>> > Note that rom_set_order_override()/rom_reset_order_override() only
>> > set/reset a switch variable that changes how fw_cfg files are
>> > sorted. It could be integrated into device_add code (and removed from
>> > the above function) without changing the behavior.
>> 
>> For me, the part that puts me off is interleaving CLI and QMP.
>> 
>> We process the CLI in an order few people understand, and only while
>> staring at the code.  That's bad.
>> 
>> Injecting QMP at certain points in that sequence can only make it worse.
>
> Yep, I share your unease here.. especially wrt this quoted text
> from later:
>
>   > >> Users can do as much or as little with the CLI as they want.  You'd
>   > >> probably want to set up a QMP monitor and no more.
>
> I would say that is a case of overkill. It can only make our
> lives harder as maintainers in the long term, if we have to
> worry about such arbitrary mixing of QMP and CLI. This is
> also why I'm pretty uneasy about the 'preconfig' stuff as
> implemented today in general.
>
> It is a half-way house that doesn't really give mgmt apps
> what they want, which is a 100% QAPI-only config. If mgmt
> apps start using preconfig, it won't make life any better
> for them and will also lock QEMU maintainers into supporting
> this half-way house.

Misunderstanding?  The paragraph you quoted is about this design:

    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).
    
    Users can do as much or as little with the CLI as they want.  You'd
    probably want to set up a QMP monitor and no more.
    
    device_add becomes possible at a certain state of the phase / run state
    machine.  It changes from cold to hot plug at a certain later state.

Certainly enables 100% QAPI-only config.  It just doesn't *force* you to
100%.  Feature.

> We have a bit of a track record with QEMU of introducing
> partial solutions and never quite finishing the job. There's
> little strong incentive to ever finish it, if you can freely
> mix both old and new style forever, and thus maintainers are
> burdened forever with both.
>
> IMHO, we should only try to support the non-mixed scenarios
>
>   - 100% of hardware configured via CLI args
>   - 100% of hardware configured via QAPI (whether live in
>     QMP, or fed in via a QAPI based JSON/YAML config file)
>
> so that we only have two clear cases we need to worry about
> dealing with.
>
> Focus our efforts 100% of the 100% QAPI scenario and don't
> divert energy into short term hybrid solutions.

The design above pretty much requires 100% QAPI.

It's based on the notion that there's no real difference between a CLI
option and a QMP command that doesn't return a value.  So treat the CLI
more like a monitor.

For sanity's sake, make it not race with the other monitors by starting
them suspended.

This design is arguably *less* hybrid than one that treats a (severely
dumbed down) CLI unlike a monitor.