All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduardo Habkost <ehabkost@redhat.com>
To: Jiri Denemark <jdenemar@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>,
	Richard Henderson <rth@twiddle.net>,
	qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 0/2] i386: "unavailable-features" QOM property
Date: Wed, 22 May 2019 11:44:12 -0300	[thread overview]
Message-ID: <20190522144412.GR10764@habkost.net> (raw)
In-Reply-To: <20190522082741.GI2545064@orkuz.int.mamuti.net>

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


      reply	other threads:[~2019-05-22 15:01 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-22 23:47 [Qemu-devel] [PATCH 0/2] i386: "unavailable-features" QOM property Eduardo Habkost
2019-04-22 23:47 ` Eduardo Habkost
2019-04-22 23:47 ` [Qemu-devel] [PATCH 1/2] i386: x86_cpu_list_feature_names() function Eduardo Habkost
2019-04-22 23:47   ` Eduardo Habkost
2019-04-22 23:47 ` [Qemu-devel] [PATCH 2/2] i386: "unavailable-features" QOM property Eduardo Habkost
2019-04-22 23:47   ` Eduardo Habkost
2019-05-09 13:35 ` [Qemu-devel] [PATCH 0/2] " Jiri Denemark
2019-05-09 13:56   ` Eduardo Habkost
2019-05-09 15:26     ` Jiri Denemark
2019-05-09 16:08       ` Eduardo Habkost
2019-05-10 11:33         ` Jiri Denemark
2019-05-10 20:23           ` Eduardo Habkost
2019-05-22  8:42             ` Jiri Denemark
2019-05-22 17:46               ` Eduardo Habkost
2019-05-09 16:06     ` Igor Mammedov
2019-05-09 16:36       ` Jiri Denemark
2019-05-10 20:32         ` Eduardo Habkost
2019-05-22  8:27           ` Jiri Denemark
2019-05-22 14:44             ` Eduardo Habkost [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190522144412.GR10764@habkost.net \
    --to=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=jdenemar@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.