qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/2] i386: "unavailable-features" QOM property


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH 0/2] i386: "unavailable-features" QOM property
Date: Wed, 22 May 2019 11:44:12 -0300
User-agent: Mutt/1.10.1 (2018-07-13)

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 <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]