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

[Marcel Apfelbaum <marcel@redhat.com>]

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?

>
[...]
>>> Big job, though.
>> You lost me... you are talking about QAPI that I have no knowledge about,
>> and I still don't see how I can create instances of QOM objects in the context
>> of qemu-config.
>
> Very high level summary:
>
> 0. We use QemuOpts to define our command line.  The definition is
> *incomplete*.  The missing parts are left to code.
> query-command-line-options can't see them.
OK

>
> 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.

>
> 2. We've solved this in several different ways, and all of them make
> query-command-line-options useless.
Got it

>
> 3. Same problem exists in QMP, and we have a decent solution there,
> based on QAPI.
OK
>
> 4. We'll soon have QMP/QAPI introspection.
And then we can query a 'living' object's properties

>
> 5. If we used a QAPI schema to define our command line, we could do a
> more complete job (because it's more expressive), and we'd get
> introspection basically for free.
If the QAPI schema will include *all* properties *per* machine type, sure.

>
> 6. #5 would be a big job, though.
>
> Less confused now?
Much better, thanks!
Marcel

> [...]