On 04/01/2015 11:36 AM, Marcel Apfelbaum wrote: > On 04/01/2015 08:29 PM, Eric Blake wrote: >> On 04/01/2015 10:47 AM, Marcel Apfelbaum wrote: >>> Commit 49d2e64 (machine: remove qemu_machine_opts global list) >>> made machine options specific to machine sub-type, leaving >>> the qemu_machine_opts desc array empty. Sadly this is the place >>> qmp_query_command_line_options is looking for supported options. >>> >>> As a fix for for 2.3 the machine_qemu_opts (the generic ones) >>> are restored only for qemu-config scope. >>> We need to find a better fix for 2.4. >>> >>> Reported-by: Tony Krowiak >>> Signed-off-by: Marcel Apfelbaum >>> --- >> >> No longer a strict superset of the Fedora 21 qemu-kvm, which had: >> >> "parameters": [ >> { >> "name": "max-ram-below-4g", >> "name": "kvm-type", >> (remembering that query-command-line-options does things in reverse >> order). I don't think iommu and suppress-vmdesc hurt to add, but we >> shouldn't lose kvm-type or max-ram-below-4g, if those were advertised at >> the point prior to the QemuOpts conversion. (I didn't actually >> research, though, whether I'm comparing against downstream Fedora >> qemu-kvm patches instead of upstream...) > Hmm, in 2.3 kvm-type and max-ram-below-4g are machine specific. > I only took the ones from hw/core/machine.c that are common to all > machines. > As you said, this approach does the best to not lie to libvirt... And luckily, libvirt is not (currently) looking for either 'kvm-type' or 'max-ram-below-4g'. So, I can live with this, and from the point of view of libvirt's interaction with qemu: Reviewed-by: Eric Blake Tested-by: Eric Blake -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org