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

[Marcel Apfelbaum <marcel@redhat.com>]

On 04/01/2015 11:28 AM, Markus Armbruster wrote:
> Marcel Apfelbaum <marcel.apfelbaum@gmail.com> writes:
>
>> On 03/31/2015 05:21 PM, Tony Krowiak wrote:
>>> Commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 removed the QemuOptDesc elements from the
>>> *desc* field of the *qemu_machine_opts *array defined in vl.c.  Since applying that patch to qemu
>>> on my system, I can not start a guest from libvirt when certain machine options are configured
>>> for the guest domain.  For example, if I configure the following for my guest domain:
>>>
>>>       <memoryBacking>
>>>           ...
>>>           <nosharepages>
>>>           ...
>>>       </memoryBacking>
>>>
>>> I get the following libvirt error when I try to start the guest:
>>>
>>>       error: unsupported configuration: disable shared memory is not available with this QEMU binary
>>>
>>> The *nosharepages *element generates the *-machine* option *mem-merge=off* on the QEMU command line.  The error is
>>> thrown by libvirt because the QMP *query-command-line-options* command does not return *mem-merge* in the machine
>>> options parameter list.  In fact, if I issue the *query-command-line-options* command via virsh as follows:
>>>
>>>       virsh qemu-monitor-command guest_c2aa '{ "execute": "query-command-line-options", "arguments": { "option": "machine" } }'
>>>
>> Hi Tony,
>> Thank you for finding this bug.
>
> Sounds like a regression.  If it is, we need to decide what to do about
> it urgently.
Hi Markus,
This is definitely a regression.

>
>>> No machine option parameters are returned:
>>>
>>> {"return":[{"parameters":[],"option":"machine"}],"id":"libvirt-11"}
>> Indeed, we have a problem here.
>>
>> This is the first object for which QemuOps are defined per
>> sub-type and are not global (if you don't take "object" under consideration).
>> I saw others as well, like netdev, but I am not sure what happens there.
>>
>> Once the QemuOpts are parsed, the only place we can find those options
>> is the machine object itself (as QOM properties).
>>
>> I see a few options here:
>> 1. Add a feature to QemuOpts: "Look for options in QOM properties of this obj"
>
> QemuOpts is an overengineered, self-contained mess.  Let's not make it
> an overengineered mess with complex external dependencies.
>
>> 2. Add a callback to QEMU opts that supplies the options (have machine
>> supply the callback)
>
> Keeps QemuOpts and QOM more separated than 1, but still adds external
> dependencies.
>
>> 3. Have the machine object fill in the corresponding QemuOpts on init.
>
> Monkey-patching QemuOpts desc[] should be workable in principle.
>
> However, to monkey-patch qemu_machine_opts.desc[], we need the machine
> object, and to create the machine object, we need to parse machine
> options.  Thus, we'll first parse with an empty desc[], then make one up
> and monkey-patch it in just for introspection.  Nasty.

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

>
> "Nasty" may well be what we need to fix the regression at this late
> hour.

I don't like it either but if 1. and 2. are worse, I posted a patch for 3. ish.

>
>> Any thoughts?
> [...]
>
> Yes, but you may not like them :)

Thanks  for the ideas!
Now I'll start reading...

>
> 4. Support tagged unions in QemuOpts
>
> QemuOpts supports a single list of typed parameters.  Good enough for
> many options.  Certain options, however, additionally take "variant"
> paramaters depending on the value of a discriminator parameter.
>
> Example: -tpmdev id=ID,type=T,...
>
>      type=T selects a TPM backend, which defines additional option
>      parameters.
>
>      Current solution: qemu_tpmdev_opts.desc[] is empty.  Option parsing
>      accepts arbitrary parameters unchecked in addition to the special
>      parameter id=ID.  configure_tpm() gets parameter "type", finds the
>      backend, then passes the backend's QemuOptsDesc[] to
>      qemu_opts_validate() to check parameters.
>
>      How configure_tpm() validates parameters is not visible to
>      query-command-line-options, naturally.
>
> Example: -device id=ID,driver=D,bus=B,...
>
>      driver=D selects a device model, which defines additional option
>      parameters.
>
>      Current solution: the device model defines QOM properties,
>      qemu_device_opts.desc[] is empty.  Option parsing accepts arbitrary
>      parameters unchecked in addition to the special parameter id=ID.
>      qdev_device_add() gets parameter "driver" and "bus", finds the
>      driver, then feeds the remaining option parameters to
>      object_property_parse() to check and set them.
>
>      How qdev_device_add() validates parameters is not visible to
>      query-command-line-options, naturally.  But libvirt knows what it
>      does, and finds the QOM properties elsewhere (QMP command
>      device-list-properties).
>
>      Related: QMP command device_add has not been QAPIfied.  We'll get
>      back to that in a jiffie.
>
> Example: -netdev id=ID,type=T,...
>
>      type=T selects a net backend, which defines additional option
>      parameters.
>
>      Current solution: qemu_netdev_opts.desc[] is empty.  Option parsing
>      accepts arbitrary parameters unchecked in addition to the special
>      parameter id=ID.  The QAPI schema defines type NetClientOptions as a
>      tagged union.  net_client_init() uses OptsVisitor to check
>      parameters and create a NetClientOptions object for them.
>
>      How net_client_init() validates parameters is not visible to
>      query-command-line-options, naturally.
>
>      We could do better in QMP, but we don't: netdev_add doesn't use
>      NetClientOptions, it uses the top type '**', which makes the QMP
>      core accept an arbitrary JSON value.  This is then converted to
>      QemuOpts and fed to the machinery described above.
>
>      Creating new infrastructure is exciting, converting the first 90% of
>      its users proves its worth, converting the other 90% is boring and
>      hard, so let's create something new and more exciting instead.
>
> The -netdev example shows that the QAPI schema already has what we need.
> QMP gets it for free, because it's based on QAPI (except the parts we
> can't be bothered to convert).
>
> We could do the same for command line options.  Would additionally get
> us other QAPI goodies, like a saner type system, and (soon)
> introspection.
>
> 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.

>
> We could of course hack up QemuOpts some more to make it support tagged
> unions all by itself, duplicating selected parts of QAPI.  Very
> traditional.
>
> 5. Introspect something else
>
> Remember the -device example?  There, query-command-line-options is of
> no help, so we find the information somewhere else.
-device is also looking into a static array, no introspection :(

>
> Adding an ad hoc "somewhere else" just for -machine would also be very
> traditional.
Thanks for the help!
Marcel

>
> [...]
>