On Wed, May 22, 2019 at 10:27:41AM +0200, Jiri Denemark wrote: > On Fri, May 10, 2019 at 17:32:03 -0300, Eduardo Habkost wrote: > > On Thu, May 09, 2019 at 06:36:18PM +0200, Jiri Denemark wrote: > > > On Thu, May 09, 2019 at 18:06:03 +0200, Igor Mammedov wrote: > > > > On Thu, 9 May 2019 10:56:17 -0300 > > > > Eduardo Habkost <ehabk...@redhat.com> wrote: > > > > > > > > > On Thu, May 09, 2019 at 03:35:37PM +0200, Jiri Denemark wrote: > > > > > > Would this unavailable-features property contain only canonical > > > > > > names of > > > > > > the features or all possible aliases of all features? For example, > > > > > > "tsc-adjust" can also be spelled as "tsc_adjust". When calling > > > > > > query-cpu-model-expansion, we have a way to request all variants by > > > > > > running full expansion on the result of a previous static > > > > > > expansion. Can > > > > > > we get something like this for unavailable-features too? > > > > > > > > > > I'd like to avoid that, and refer only to the canonical names. > > > > > > > > Can we deprecate aliases to avoid confusion in future? > > > > (there aren't that many of them that used pre-QOM name format) > > > > > > If you come up with a way libvirt could use to detect which name it > > > should use when talking to QEMU... > > > > The property names are part of the API, and deprecation would > > just be documented in the QEMU documentation. Why would you need > > to enumerate them dynamically at runtime? > > The tricky part is to know which variant of a particular feature name we > should use when talking to a specific version of QEMU. But I guess we > can use the new "unavailable-features" property for this purpose. [...]
You can run device-list-properties on the typenames returned by query-cpu-definitions, to check which CPU properties exist in a QEMU binary. > [...] When > the property is present, we can translate all feature names to their > canonical names (via a static translation table in libvirt). We'd be > using the old untranslated names when talking to any QEMU which does not > support the "unavailable-features" property. That would help us simplify the interface between QEMU and libvirt. > > But I hope we won't get into a situation when some CPU feature needs to > be renamed again, that would make a big mess. I promise we'll try to avoid doing that. :) -- Eduardo
