-----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----- -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list