From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57031) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UYHRh-0003h5-2R for qemu-devel@nongnu.org; Fri, 03 May 2013 10:58:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UYHRf-0002wt-OT for qemu-devel@nongnu.org; Fri, 03 May 2013 10:58:49 -0400 Received: from cantor2.suse.de ([195.135.220.15]:37941 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UYHRf-0002wm-Fh for qemu-devel@nongnu.org; Fri, 03 May 2013 10:58:47 -0400 Message-ID: <5183D0A4.7000200@suse.de> Date: Fri, 03 May 2013 16:58:44 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1366657220-776-1-git-send-email-ehabkost@redhat.com> <51819CED.5070300@suse.de> <20130502194301.GV28606@otherpad.lan.raisama.net> <5182C328.4000503@redhat.com> In-Reply-To: <5182C328.4000503@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH qom-cpu 0/9] x86: feature words array (v11) + "feature-words" property List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , Eduardo Habkost Cc: qemu-devel@nongnu.org, libvir-list@redhat.com, Markus Armbruster , Luiz Capitulino , Anthony Liguori , Igor Mammedov , Jiri Denemark -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 02.05.2013 21:48, schrieb Eric Blake: > On 05/02/2013 01:43 PM, Eduardo Habkost wrote: >>>=20 >>> As mentioned earlier I'd prefer to defer the property design >>> rather than putting it lightly reviewed into 1.5 and living >>> with some ABI. If libvirt urgently needs this info, this series >>> needs to be reviewed and sorted out until the weekend (Hard >>> Freeze on Monday). >>=20 >> I consider it an important bugfix for the QEMU+libvirt stack. >> The current libvirt behavior (checking CPUID directly; not using >> the "enforce" flag; and having its own copy of each CPU model >> definition) is unsafe and may break live-migration silently under >> many circumstances. >=20 > I agree that libvirt would very much like to have this in 1.5. How > can I help in reviewing things? Apart from the usual QMP considerations that you will know much better than me, I have two concerns here: 1) Polluting the QOM namespace with this dump-all implementation for libvirt and interfering with more fine-grained property getters/setters. 2) Basing its design on current code of which we are not sure yet how it may evolve and having to live with that for ABI stability. Like I said, I hadn't reviewed that part yet, so couldn't pick it up on short notice. If we get it respun and reviewed today, I can (try to) prepare a PULL on Sunday. On Igor's series (latest: v7 from Feb 25) I had more or less nack'ed the attempt to introduce f-* properties due to Anthony asking for verbose QOM property names, so we're in need of a better name, likely something with "feature" in it, similar to what is being proposed here. I had also argued with Anthony that QOM's object_property_add_bool() should allow us to create a container object for accessing features in a more simple way, such as .../icc/child[0]/cpuid-features/foo rather than f-foo or feature-foo or foo-feature to avoid the constant repetition and an unreadable long list of CPU properties, but the addition of an opaque to support this was turned down. So it boils down to the questions of where do we want to expose which information, how should it be structured and where does/will that information come from. Thanks. Regards, Andreas - --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRg9CkAAoJEPou0S0+fgE/Mu8P/1FFoXTMawQ2o8np/cjOFEze zv+MJ5DUKZK96PPNoZjsM8y0tmNZ8VT9q578AQuElQiA/AbOaUqEoqL/NB9i9Bqc PBZw7KwgNkH8Mogw7izOmOybKZbshdin9uBxRugG+Xyg5Nk7oMYkTQV8PLHmAgRc LxgeMAJHsPY9LXksCNUbZNblK//EQfP90e7v0fU+ys5xrlCFlCl1xRQd9Cw2QvHd 7gECUSlwOlkHY32BFEn/epqay45uZqlECyGXDqrssg5htLM5McbzKCa1sgdQbuqp HqsO3WdM6jBrse5EApxdoaYmz8Yhl6ls+YOQY+l3DjjhHNcDzxtIqbAK36ErBHFz 9d+NTcXBlGrC0N0L7VZmwLihJ3bT/IIEP7ybLFN/QKHlz4H83pEGftbBpPipqrwq NZWk7Z6IiOKptxNyBKOa04+2DJvlafgwjysfTf5bjEQ+WDTEeMoubIOZiG9bC1bm WdqAC6JzQYTpjT3kqbfxGlV8328N3Z1qrVpRZOevkPHpotaaSDa5VVSCOvj6hdJZ P4L2hq94bskumINJWHZxYEGvrB+6MJfOn73icNSpzyg+2sVw2QVfVAfbe0XfGFag 2JO5sFbl0be8rOh6Y7b2uxltfI1RnGIBmemRQkjP6Z3mynLs7EYKqs8LwpHR0FMm 3oSPrNXELr02m/9eGpsb =3DtUDY -----END PGP SIGNATURE-----