Hi Markus,
It looks promising. I did not think we could so "easily" have a new
working startup. But I'm not so sure that I understand how we should
progress from here.
I see 3 main parts in this:
A. introducing new binary (meson, ...)
B. startup api: phase related stuff (maybe more)
C. cli to qmp parser
I think if we want to add a new binary (instead of replace it), there
will be some common api and every startup will have to support/implement
it. Probably some part of vl.c will have to go in some common code.
In practice, we probably should introduce/extract this before
introducing the new binary.
One central part of this api is the phase mechanism (even if legacy
startup can only support it partially or not-at-all).
I think we have 2 choices:
+ we have to use until_phase explicitly
+ we make qmp commands implicitly advances phases when needed.
I think it's better to go the implicit way as much as possible: it means
we focus on commands and not on some artificial phases we set up because
of legacy.
Either way, we probably should put the phase info in qapi so that we
don't have to hardcode that in every command in order to have common
error handling. One thing we could do is replace "allow-preconfig" in
qapi by some phase requirement entry(entries?) and make qmp call
qemu_until_phase() or some qemu_phase_check() function.
We also maybe need to sort out if we want to merge the phases into the
runstate.
Thanks for making the effort to do this rfc,
--
Damien
On 12/2/21 08:04, Markus Armbruster wrote:
These patches are meant to back the memo "Redesign of QEMU startup &
initial configuration" I just posted. Read that first, please.
My running example for initial configuration via QMP is cold plug. It
works at the end of the series.
I'm taking a number of shortcuts:
* I hack up qemu-system-FOO instead of creating an alternate program.
Just so I don't have to mess with Meson.
* Instead of creating QAPI/CLI infrastructure, I use QMP as CLI: each
argument is interpreted as QMP command. This is certainly bad CLI,
but should suffice to demonstrate things.
* Instead of feeding the CLI's QMP commands to the main loop via a
quasi-monitor, I send them directly to the QMP dispatcher. Simpler,
but I'm not sure that's going to work for all QMP commands we want.
* Phase advance is by explicit command @until-phase only. Carelessly
named. We may want some other commands to advance the phase
automatically.
* There are no safeguards. You *can* run QMP commands in phases where
they crash. Data corruption is left as an exercise for the reader.
* Possibly more I can't remember right now :)
Markus Armbruster (11):
vl: Cut off the CLI with an axe
vl: Drop x-exit-preconfig
vl: Hardcode a QMP monitor on stdio for now
vl: Hardcode a VGA device for now
vl: Demonstrate (bad) CLI wrapped around QMP
vl: Factor qemu_until_phase() out of qemu_init()
vl: Implement qemu_until_phase() running from arbitrary phase
vl: Implement qemu_until_phase() running to arbitrary phase
vl: New QMP command until-phase
vl: Disregard lack of 'allow-preconfig': true
vl: Enter main loop in phase @machine-initialized
qapi/misc.json | 27 -
qapi/phase.json | 31 +
qapi/qapi-schema.json | 1 +
include/hw/qdev-core.h | 31 -
hw/core/machine-qmp-cmds.c | 1 +
hw/core/machine.c | 1 +
hw/core/qdev.c | 7 +
hw/pci/pci.c | 1 +
hw/usb/core.c | 1 +
hw/virtio/virtio-iommu.c | 1 +
monitor/hmp-cmds.c | 8 -
monitor/hmp.c | 1 +
softmmu/qdev-monitor.c | 3 +
softmmu/vl.c | 2833 ++----------------------------------
ui/console.c | 1 +
MAINTAINERS | 1 +
hmp-commands.hx | 18 -
qapi/meson.build | 1 +
18 files changed, 180 insertions(+), 2788 deletions(-)
create mode 100644 qapi/phase.json