Re: [RFC V1 00/14] precreate phase

[Paolo Bonzini <pbonzini@redhat.com>]

On 10/17/24 17:14, Steve Sistare wrote:
> Define a new qemu initialization phase called 'precreate' which occurs
> before most backends or devices have been created.  The only exception
> is monitor and qtest devices and their associated chardevs.
> 
> QEMU runs in the main loop during this phase.  Monitor connections are
> active and can receive migration configuration commands.  QEMU starts
> listening on the normal migration URI during this phase, which can come
> from either the QEMU command line or from a migrate_incoming command.
> Thus the user can issue query-migrate to get the socket-address for
> dynamically allocated port numbers during precreate.
> 
> In this series QEMU passes through and does not linger in the precreate
> phase, and the user sees no change in behavior.  The cpr-transfer series
> will linger in the phase for an incoming CPR operation, and exit the phase
> when the migrate command is send to source QEMU and causes destination QEMU
> to read CPR state.
> 
> A future series may wish to add a command-line argument and monitor
> command that enters and exits the precreate phase for general purpose use.
> That would enable the user to issue monitor commands that specify backend
> creation parameters.

I have a problem with the concept, which is that the split between 
command line and monitor is much harder to understand.

Ideally, one would come entirely before the other; preconfig is already 
ugly in how -device is processed later than everything else[1].  This 
series makes this much more complex.

If I understand correctly, what you want is effectively to execute 
monitor commands from the migration stream.  If you want to do that, we 
need to take more qemu_init code and turn it into QMP commands, so that 
precreate can exit qemu_init very early and the "after precreate" 
command line options can be replaced by interactions on the monitor.

This is the idea that drove the creation of -M smp.xxx, -M boot.xxx, -M 
memory.xxx, etc. (see for example commit 8c4da4b5218, "machine: add boot 
compound property", 2022-05-12).  For example -semihosting-config, 
-acpitable, -smbios, -fw_cfg, -option-rom, -rtc could all become -M 
properties and handled by a single monitor command machine-set.

Of all the other options, -accel, -cpu and -display are the main missing 
ones (-cpu is the very hard one); a full list is at 
https://wiki.qemu.org/User:Paolo_Bonzini/Machine_init_sequence#QMP_configuration_flow.

Anyhow, at this point all that's needed is a -chardev/-mon pair (and I 
guess -incoming defer) in order to bootstrap the monitor in precreate mode.

It's okay to prototype without full support for the options I've listed, 
but if we want to go with precreate we should make most command line 
options entirely incompatible with it, and also make it imply -nodefaults.

Paolo

[1] -loadvm and -incoming too; but for those two we could make their 
monitor commands exit preconfig mode automatically, and invoke them from 
the monitor instead of specifying them on the command line.