From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42396) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdLY9-0007A1-VI for qemu-devel@nongnu.org; Wed, 01 Apr 2015 12:31:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YdLY5-0005zY-VM for qemu-devel@nongnu.org; Wed, 01 Apr 2015 12:31:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41274) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdLY5-0005yz-B4 for qemu-devel@nongnu.org; Wed, 01 Apr 2015 12:31:25 -0400 Message-ID: <551C1D57.7000705@redhat.com> Date: Wed, 01 Apr 2015 19:31:19 +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> <551C05F0.3090502@redhat.com> <87k2xvonem.fsf@blackfin.pond.sub.org> <551C18C2.50306@redhat.com> <551C1ADD.50809@redhat.com> In-Reply-To: <551C1ADD.50809@redhat.com> Content-Type: text/plain; charset=utf-8; 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: Eric Blake , Markus Armbruster Cc: Paolo Bonzini , Tony Krowiak , qemu-devel@nongnu.org, =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= 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 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. >