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

["Andreas Färber" <afaerber@suse.de>]

-----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.
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

- -- 
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-----