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

[Marcel Apfelbaum <marcel@redhat.com>]

On 04/01/2015 07:20 PM, Eric Blake wrote:
> 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).
OK I'll send it shortly

Thanks,
Marcel
>
>
>>> 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.
>