I cc-ed Igor because he worked on preconfig support.
On 5/13/21 7:52 PM, Paolo Bonzini wrote:
Hi Mirela, this is very interesting!
It's unfortunate that I completely missed the discussions in
January/February. You might have noticed that in the 5.2/6.0
timeframe I worked on cleaning up the machine initialization phases
and qemu_init. The idea behind the cleanup was to identify clearly
the steps from one phase to the next. I am very happy that you are
already benefitting from that work in this series and you were able to
make a prototype with so little code.
My plan was a bit more ambitious though :) and it is laid out at
https://wiki.qemu.org/User:Paolo_Bonzini/Machine_init_sequence.
My plan was to have completely different binaries than the current
qemu-system-*. These would only have a handful of command line
options (such as -name, -sandbox, -trace, -L) and would open a QMP
connection on stdio.
All other command line option would be either considered legacy or
adjusted to be part of two new QMP commands, machine-set and
accel-set, which would advance through the phases like this:
PHASE_NO_MACHINE
-> machine-set -> PHASE_MACHINE_CREATED ->
-> accel-set -> PHASE_ACCEL_CREATED -> PHASE_MACHINE_INITIALIZED ->
My understanding is that an equivalent of previously supported
'preconfig' state is PHASE_ACCEL_CREATED, from the perspective of the
QMP configuration that Igor implemented. In other words, I believe that
when -preconfig CLI option was passed, QEMU was waiting for the QMP
configuration in PHASE_ACCEL_CREATED phase. Now, if accel-set advances
the machine directly to PHASE_MACHINE_INITIALIZED, there will be no
chance to configure what Igor did with -preconfig.
Is this something you don't want to support anymore, or it can be
configured in another way? Or is this something that we haven't thought
of yet, but we should?
Another point I'm trying to make here - sooner or later I believe we
will run again into the issue similar to the one described above. I
truly believe that the commands you proposed (machine-set and accel-set)
should be kept as is, except that they wouldn't automatically advance
the machine initialization phase. I think the best approach would be to
combine your proposal with mine: the machine-set and accel-set commands
would configure stuff as you proposed, but there will be separate
commands to advance machine phases (next-machine-phase and
target/set-machine-phase). I also believe such a separation would be
extremely important for troubleshooting configurations.
Btw, we already have such a separation because we will reuse device_add
command, that only does the configuration. I believe it will be much
cleaner and flexible for future development to separate QMP commands
into 1) those that configure stuff, and 2) those that control advancing
of the machine init phases.
Moreover, once it turns out that a command receives too many arguments
and should be split into few, it will be easier to do so if a single
command did not include both configuration and control-flow. Similar
holds for adding new commands into the flow.
Please let me know what you think about the proposal.
Thanks,
Mirela
-> finish-machine-init -> PHASE_MACHINE_READY
-> cont
I think this idea would work well with your plan below, because the
preconfiguration that you need to do happens mostly at
PHASE_MACHINE_INITIALIZED.
Of course, the disadvantage of my approach is that, in the initial
version, a lot of capabilities of QEMU are not available (especially
with respect to the UI, since there's no "display-add" command).
However, the basic implementation of machine-set and accel-set should
not really be *that* much more work, and it should be doable in
parallel with the conversion efforts for those options. For example,
today I posted a series that maps -smp to -M (and then, SMP
configuration would automatically become available in machine-set).
I have placed the skeleton of the work I was doing at
https://gitlab.com/bonzini/qemu/ in the branch qemu-qmp-targets. You
can see a sample execution at
https://asciinema.org/a/TXMX8EZh8Md0fZnuE7uhfv6cO. I have not touched
some of the patches in a long time, but I plan to give them a quick
test tomorrow. Starting from the code in that branch, it should not
be hard to implement the machine-set and accel-set commands in the
same fashion as QEMU 5.2's implementation of object-add.
Thanks for posting these patches, I have started a light review of them.
Paolo
On 13/05/21 10:25, Mirela Grujic wrote:
The direction for this work has been set in the discussion thread:
"About creating machines on the command line" in January/February 2021:
https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg01839.html
https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg01070.html
To customize a machine via QMP we need the ability to stop QEMU at a
specific
machine initialization phase.
Currently, machine initialization phases are:
1) no-machine: machine does not exist yet (current_machine == NULL)
2) machine-created: machine exists, but its accelerator does not
(current_machine->accelerator == NULL)
3) accel-created: machine's accelerator is configured
(current_machine->accelerator != NULL), but machine class's
init() has not
been called (no properties validated, machine_init_done notifiers
not
registered, no sysbus, etc.)
4) initialized: machine class's init() has been called, thus machine
properties
are validated, machine_init_done notifiers registered, sysbus
realized, etc.
Devices added at this phase are considered to be cold-plugged.
5) ready: machine_init_done notifiers are called, then QEMU is ready
to start
CPUs. Devices added at this phase are considered to be hot-plugged.
QEMU can be stopped today using the -preconfig CLI option at phase 3
(accel-created). This option was introduced to enable the QMP
configuration of
parameters that affect the machine initialization. We cannot add
devices at
this point because the machine class's init() has not been called,
thus sysbus
does not exist yet (a device cannot be added because there is no bus
to attach
it to).
QEMU can be also stopped using the -S CLI option at the machine ready
phase.
However, it is too late to add devices at this phase because the
machine is
already configured, and any devices added at this point are
considered to be
hot-plugged.
Since the existing -preconfig CLI option stops QEMU too early, and
the -S option
stops too late, we need a way to stop QEMU in between (after the
machine is
initialized and before it becomes ready).