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

[Markus Armbruster]

Marcel Apfelbaum <address@hidden> writes:

> On 04/01/2015 11:28 AM, Markus Armbruster wrote:
>> Marcel Apfelbaum <address@hidden> 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 :(.

You'd have to do something like

  desc[] = generic entries + the machine's entries

where the latter is empty outside qemu proper.

For 2.3, I recommend to do *only* generic entries.  Specifically,
*exactly* the entries we had before we cleared out
qemu_machine_opts.desc[].

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

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.

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

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

3. Same problem exists in QMP, and we have a decent solution there,
based on QAPI.

4. We'll soon have QMP/QAPI introspection.

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.

6. #5 would be a big job, though.

Less confused now?

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

Let me rephrase:

query-command-line-options comes up empty for -device.

Libvirt knows that -device takes parameters "id", "driver" and
driver-specific ones.  It further knows how to get the driver-specific
ones: with QMP command device-list-properties.  Example:

    { "execute": "device-list-properties", "arguments": { "typename": 
"usb-mouse" }  }
    {"return": [{"name": "msos-desc", "description": "on/off", "type": "bool"}, 
{"name": "full-path", "description": "on/off", "type": "bool"}, {"name": 
"serial", "type": "str"}, {"name": "port", "type": "str"}, {"name": 
"usb_version", "type": "uint32"}]}

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