Re: [Qemu-devel] [qemu devel] disable shared memory is not available with this QEMU binary

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2738 bytes --]

On 04/01/2015 10:11 AM, Marcel Apfelbaum wrote:
> On 04/01/2015 06:53 PM, Markus Armbruster wrote:
>> Marcel Apfelbaum <marcel@redhat.com> writes:
> [...]
>>> I noticed something weird. I cannot actually create an instance of
>>> machine
>>> or get a reference to current_machine in order to query its properties!
>>>
>>> It seems that util/qemu-config is used by qemu-img which obviously
>>> does not have a current machine nor the means to create it.
>>>
>>> So I have no way to create QOM objects for introspection :(.
>>
>> You'd have to do something like
>>
>>    desc[] = generic entries + the machine's entries
>>
>> where the latter is empty outside qemu proper.
> Hmm! So I will loose with some dignity.
> I'll keep the properties of the base "machine" on a static array
> and *only* per-machine properties dynamic and I loose them.
> 
>>
>> For 2.3, I recommend to do *only* generic entries.  Specifically,
>> *exactly* the entries we had before we cleared out
>> qemu_machine_opts.desc[].
> I submitted:
>   [PATCH for-2.3] util/qemu-config" fix regression of
> qmp_query_command_line_options
> which includes both base-machine/per-machine properties.
> Is it that bad? qmp can query it and even the new options will work
> if qmp decides to set them. Can you have a look?

The problem is that the per-machine properties are ALSO advertised even
on machines where they do not work, which means you could be lying to
libvirt if it needs to know if a specific per-machine option is present.
 It would indeed be more conservative for 2.3 to advertise ONLY the
generic options, so even though I already reviewed your patch, you may
want to respin to incorporate the more conservative approach by dropping
the advertising of any machine-specific option (as that is no worse than
what we had before - better to not advertise a feature than to advertise
something we don't actually support).


>> 1. You have a QemuOpts problem that is actually pretty common: how to
>> accept a few fixed parameters plus a bunch of parameters that are
>> specific to the value of one of the fixed parameters (the
>> discriminator, in your case "type").
> Yes, but is more than that:
> per-type properties are not static, you cannot find them before creating
> an actual QOM object, and that is not possible.
> 
> We could have a per-machine static options array that will be loaded
> at init time into object properties... ugly.

But we can avoid worrying about the ugliness or alternatives for solving
that until 2.4.  For 2.3, all we need to focus on is avoiding the
regression.

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]