Re: [Qemu-devel] [PATCH qom-cpu 0/9] x86: feature words array (v11) + "feature-words" property

[Igor Mammedov <imammedo@redhat.com>]

On Fri, 03 May 2013 16:58:44 +0200
Andreas Färber <afaerber@suse.de> wrote:

> -----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:
> >>> 
> >>> 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).
> >> 
> >> 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.
> > 
> > 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.
I think feature-words could be replaced with fine-grained feature properties
eventually.

> 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
I don't recall it being nacked or any other way commented.

> 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.
what if FeatureWordArray inherits from Object?
than it would be trivial to create /icc/child[0]/cpuid-features/ where
"cpuid-features" will be FeatureWordArray and each feature it's child?

> 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
> 
> - -- 
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nü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
> =tUDY
> -----END PGP SIGNATURE-----


-- 
Regards,
  Igor