From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37392) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdJzb-0002rc-CI for qemu-devel@nongnu.org; Wed, 01 Apr 2015 10:51:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YdJzS-0002co-Nw for qemu-devel@nongnu.org; Wed, 01 Apr 2015 10:51:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40945) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdJzS-0002cg-G3 for qemu-devel@nongnu.org; Wed, 01 Apr 2015 10:51:34 -0400 Message-ID: <551C05F0.3090502@redhat.com> Date: Wed, 01 Apr 2015 17:51:28 +0300 From: Marcel Apfelbaum MIME-Version: 1.0 References: <551AAD75.8090909@linux.vnet.ibm.com> <551B963E.9060800@gmail.com> <87oan8z1yw.fsf@blackfin.pond.sub.org> In-Reply-To: <87oan8z1yw.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [qemu devel] disable shared memory is not available with this QEMU binary List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Paolo Bonzini , Tony Krowiak , qemu-devel@nongnu.org, =?windows-1252?Q?Andreas_F=E4rber?= On 04/01/2015 11:28 AM, Markus Armbruster wrote: > Marcel Apfelbaum 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: >>> >>> >>> ... >>> >>> ... >>> >>> >>> 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 > > [...] >