qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH V2 for-2.3] util/qemu-config: fix regression of


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH V2 for-2.3] util/qemu-config: fix regression of qmp_query_command_line_options
Date: Wed, 01 Apr 2015 12:20:30 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

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 <address@hidden>
>>> Signed-off-by: Marcel Apfelbaum <address@hidden>
>>> ---

>>
>> 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 <address@hidden>

Tested-by: Eric Blake <address@hidden>

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]