Paolo Bonzini <pbonz...@redhat.com> writes: > 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-*.
Now you have 2x problems :) > 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 -> > -> finish-machine-init -> PHASE_MACHINE_READY > -> cont Is machine-set one big command, or a sequence of commands, where each command configures just one thing? Same for accel-set. Permit me to go off on a tangent: how much and what kind of magic do we want in the initialization sequence? The existing order is a confusing mess grown out of a half-hearted attempt to make things just work. We've talked about it a few times, e.g. here: Message-ID: <87poomg77m....@dusky.pond.sub.org> https://lists.nongnu.org/archive/html/qemu-devel/2016-09/msg00163.html Are you aiming for "leave ordering to the user", or for "do the right thing" (the user's order doesn't matter)", or for "neither; confusing messes are fun"? Another tangent: 1. A command line option is like a QMP command that returns nothing. Generating CLI options from a QAPI schema is no harder than generating QMP commands, it's just work. 2. A configuration file is like a command line, only easier to work with when configuration becomes non-trivial. Generating configuration file language from a QAPI schema is no harder than generating QMP commands / CLI options, it's just work. 3. QMP is strictly more powerful than CLI or comfiguration file. It's also less convenient for ad hoc use by humans: compare -readconfig vm123.cfg to feeding the equivalent QMP commands with socat. 4. We'll see whether the convenience for humans can motivate us to put in the work. > 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. Please cc: on future work in this area. I'm about to drop off for two weeks of vacation, though :)