All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Denemark <jdenemar@redhat.com>
To: Eduardo Habkost <ehabkost@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 10:27:41 +0200	[thread overview]
Message-ID: <20190522082741.GI2545064@orkuz.int.mamuti.net> (raw)
In-Reply-To: <20190510203203.GW4189@habkost.net>

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

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.

Jirka


  reply	other threads:[~2019-05-22  8:32 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 [this message]
2019-05-22 14:44             ` Eduardo Habkost

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=20190522082741.GI2545064@orkuz.int.mamuti.net \
    --to=jdenemar@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@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.