Hi, Below are the notes I collected during the BoF session about QEMU configuration, command-line and QMP. Sorry for taking so long to send them. All inaccuracies and mistakes below are my own fault. (I learned the hard way that trying to take notes while participating in the discussion at the same time is not a good idea.) -------------------------------- KVM Forum 2017 BoF session: configuration, command-line and QMP 2017-10-26 People: Jiri Denemark, Laine Stump, Peter Krempa, Markus Armbruster, Eduardo Habkost, Igor Mammedov, Kevin Wolf, Eduardo Otubo, Alistair Francis, Kashyap Chamarthy, Max Reitz ---------------- First topic: early QMP and -paused series by Igor ehabkost tried to explain the original problem and Igor's proposal[1]. Markus: startup time is important, some things can make it slow. Personally, not so much concerned about querying stuff. Just cache it! Markus, about starting a monitor earlier: "it just makes sense". One problem is: command-line processing ordering mess in QEMU. It's tempting but very scary. very easy to screw up. About command-line ordering, “I'd just go left-to-right”. ehabkost: is gradual change with NUMA stuff the right path? (Markus: "what's the right path?"; ehabkost: "I don't know"). If you are using CPU hotplug you still might have some stuff not appearing in the command-line, because it uses query-hotpluggable-cpus. pkrempa: if you're using cpu hotplug you don't care about startup time. NUMA is not different. Markus's objection to current -paused series: the need for another option/state. We basically have 3 states/phases: 1: between exec and monitor available 2: between monitor and machines start to runs (in that phase a device_add is/can be a cold plug) 3: then the machine actually runs, and all device_add is hotplug ehabkost: that's how I understand it, too. ehabkost: question for libvirt developers: is there an "expansion" operation where libvirt could fill-up missing data on the XML based on info queried from QEMU? (Answer seems to be yes) ---------------- Some comments from Igor and Peter about query-hotpluggable-cpus and the need to choose the right device type (sometimes TYPE_CPU is not appropriate for device_add, but only CPU cores, like on Power). ehabkost: that's probably another use case for query-device-slots: knowing that power machines can't device_add threads, but just cores. Tricky part: providing slot information at qemu-probing time (with -machine none), before any machine was built. ---------------- Some discussion about QEMU capability caching, why we need it, what we need to get rid of it (answer: early QMP?). Markus: would --query-FOO for some FOOs help? libvirt developers seem to prefer early QMP. ---------------- Now that libvirt queries QEMU for host CPUID capabilities, there are more interesting ways the cache may need to be invalidated. Markus: “there's a it of a combinatorial explosion, i.e. query results can depend on so much more than just the QEMU version and machine type. Makes invalidating the cache tricky, and possibly even finding something useful in it insufficiently likely to be worth the trouble.” ---------------- Some discussion about libvirt/qemu versions compatibility. Markus proposes that we could choose to make newer QEMU require a more recent libvirt version. OpenStack Nova re-evaluates every 6 months what next minimum libvirt and QEMU versions to use (via constants: NEXT_MIN_LIBVIRT_VERSION, NEXT_MIN_QEMU_VERSION) Markus: “The version decoupling we have is really nice, but I think an occasional dependency would be tolerable. Consider it when it saves lots of work.” Markus: “Also: drop support for old versions of QEMU. Anything before 1.5?” ---------------- References and notes: [1] References for “Early QMP”: * Igor’s proposal at: Subject: [Qemu-devel] [RFC 0/6] enable numa configuration before machine_init() from HMP/QMP https://www.mail-archive.com/qemu-devel@nongnu.org/msg488601.html * And what Eduardo has suggested at: http://www.linux-kvm.org/images/4/46/03x06A-Eduardo_HabkostMachine-type_Intr... Comments from Markus:

Related: "Why /two/ config interfaces?" in my KVM Forum talk. The two being CLI and QMP.

We've long held the idea to support starting QEMU with a minimal command line, then do all configuration via QMP. Not possible today, because lots of things can only be done via CLI. In part because QMP becomes available only after quite a few config boats have sailed.

Making QMP available earlier during startup ("early QMP") would be a stepping stone towards the "only QMP" goal.

Related: rebasing CLI onto QAPI would make replicating CLI-only interfaces in QMP easier.

-- Eduardo