[Top][All Lists]

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

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

From: Damien Hedde
Subject: Re: [RFC PATCH v3 0/5] QMP support for cold-plugging devices
Date: Thu, 25 Nov 2021 13:42:45 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2

On 11/24/21 15:51, Markus Armbruster wrote:
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.

It seems there is a big gap from where we are now to a full QAPI startup support. Could we adopt a plan which would allow us to progress from where we are to full QAPI support in small steps ?

For example, the following:

1. CLI/QMP interleaving seems to be big issue right now. We could solve this by making -preconfig stop only after all CLI options are "consumed". For example if you give -preconfig and some -device, qemu won't stop before having created the devices.

Meaning you would do
$qemu [out-of-order CLI with -preconfig] then jump into the monitors.

Depending on your use case, you would have to give a few CLI options so that -preconfig stops early enough.

2. Then we can enable QMP commands one by one corresponding to unsupported and needed/cleaned up CLI options. They will check and/or advance the phase/runstate.

Basically this would mean we have to first convert CLI options that are used last in the startup procedure.
Along the road we will be able to make -preconfig stop earlier and earlier.

You could do a ~0% CLI startup at any point during the development
$qemu -monitor... --preconfig
but you would have a reduced set of configuration possibilities due the lack of QAPI support.

In addition, optionally, if we want to go with the left-to-right CLI parsing and reading a CLI script file like Markus proposed, we could have something like:
$qemu [out-of-order CLI] --preconfig [in-order CLI]
with [in-order CLI] being a 1:1 equivalent of QMP commands. [in-order CLI] will still be parsed and executed before jumping in the monitors.


reply via email to

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