From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34573) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TQJAw-0005cl-7S for qemu-devel@nongnu.org; Mon, 22 Oct 2012 10:40:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TQJAm-00013i-KL for qemu-devel@nongnu.org; Mon, 22 Oct 2012 10:40:18 -0400 Received: from cantor2.suse.de ([195.135.220.15]:43431 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TQJAm-0000wV-B4 for qemu-devel@nongnu.org; Mon, 22 Oct 2012 10:40:08 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Alexander Graf In-Reply-To: <50855247.5060502@redhat.com> Date: Mon, 22 Oct 2012 16:39:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8823BB0E-64DF-4558-9EB7-873FA25F3433@suse.de> References: <20121021124303.GA5096@redhat.com> <5084E088.9090602@redhat.com> <20121022100821.GB24424@redhat.com> <508521F3.3070008@redhat.com> <20121022131601.GC16851@redhat.com> <50854388.6060801@redhat.com> <20121022142347.GC18658@redhat.com> <50855247.5060502@redhat.com> Subject: Re: [Qemu-devel] [PATCH v3 00/26] q35 qemu support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: aliguori@us.ibm.com, alex.williamson@redhat.com, "Michael S. Tsirkin" , jan.kiszka@siemens.com, Jason Baron , qemu-devel@nongnu.org, lcapitulino@redhat.com, blauwirbel@gmail.com, yamahata@valinux.co.jp, juzhang@redhat.com, kevin@koconnor.net, Gerd Hoffmann , mkletzan@redhat.com, pbonzini@redhat.com, afaerber@suse.de, armbru@redhat.com, avi@redhat.com On 22.10.2012, at 16:03, Eric Blake wrote: > On 10/22/2012 08:23 AM, Michael S. Tsirkin wrote: >> On Mon, Oct 22, 2012 at 07:00:56AM -0600, Eric Blake wrote: >>> On 10/22/2012 07:16 AM, Michael S. Tsirkin wrote: >>>=20 >>>> I worry about need to maintain bug for bug compatibility on the >>>> unlikely chance that the work to complete it gets delayed and we = release >>>> it in an unready state. >>>>=20 >>>>> But in any case this needs >>>>> discussion with the libvirt folks to make sure it will actually = work as >>>>> intended. /me tends to think a experimental bit in machine_info = (which >>>>> is then printed by 'qemu -M ?' and the QOM-version of that) is = more >>>>> useful than playing tricks with the name. >>>>>=20 >>>>> cheers, >>>>> Gerd >>>>=20 >>>> I agree it's best to ask libvirt folks what's the right way to hide >>>> a machine type from it. Add a flag so it's not listed in -M ? ? >>>=20 >>> For qemu 1.3, libvirt will NOT be reading '-M ?', but instead = calling >>> the 'query-machines' QMP command. If you want a machine to be = avoided >>> by libvirt, then perhaps it is best to augment the MachineInfo QMP >>> datatype to add an optional field that says whether a particular = machine >>> type is stable enough for libvirt's use. >>=20 >> Or just hide this machine type from the query-machines command? >=20 > That would probably work, as well. You would still want the testing from users behind libvirt, so hiding is = not good. Hiding by default with an experimental tag would probably be = the best. Alex