All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduardo Habkost <ehabkost@redhat.com>
To: qemu-devel@nongnu.org
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Eduardo Habkost <ehabkost@redhat.com>,
	Jiri Denemark <jdenemar@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>,
	Richard Henderson <rth@twiddle.net>
Subject: [Qemu-devel] [PATCH 0/2] i386: "unavailable-features" QOM property
Date: Mon, 22 Apr 2019 20:47:40 -0300	[thread overview]
Message-ID: <20190422234742.15780-1-ehabkost@redhat.com> (raw)

Currently, libvirt uses the "filtered-features" QOM property at
runtime to ensure no feature was accidentally disabled on VCPUs
because it's not available on the host.

However, the code for "feature-words" assumes that all missing
features have a corresponding CPUID bit, which is not true for
MSR-based features like the ones at FEAT_ARCH_CAPABILITIES.

We could extend X86CPUFeatureWordInfo to include information
about MSR features, but it's impossible to do that while keeping
compatibility with clients that (reasonably) expect all elements
of "filtered-features" to have the cpuid-* fields.

We have a field in "query-cpu-definitions" that already describes
all features that are missing on a CPU, including MSR features:
CpuDefinitionInfo.unavailable-features.  The existing code for
building the unavailable-features array even uses
X86CPU::filtered_features to build the feature list.

This series adds a "unavailable-features" QOM property to X86CPU
objects that have the same semantics of "unavailable-features" on
query-cpu-definitions.  The new property has the same goal of
"filtered-features", but is generic enough to let any kind of CPU
feature to be listed there without relying on low level details
like CPUID leaves or MSR numbers.

Eduardo Habkost (2):
  i386: x86_cpu_list_feature_names() function
  i386: "unavailable-features" QOM property

 target/i386/cpu.c | 55 ++++++++++++++++++++++++++++++++++++-----------
 1 file changed, 42 insertions(+), 13 deletions(-)

-- 
2.18.0.rc1.1.g3f1ff2140

WARNING: multiple messages have this Message-ID (diff)
From: Eduardo Habkost <ehabkost@redhat.com>
To: qemu-devel@nongnu.org
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Jiri Denemark <jdenemar@redhat.com>,
	Richard Henderson <rth@twiddle.net>,
	Eduardo Habkost <ehabkost@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>
Subject: [Qemu-devel] [PATCH 0/2] i386: "unavailable-features" QOM property
Date: Mon, 22 Apr 2019 20:47:40 -0300	[thread overview]
Message-ID: <20190422234742.15780-1-ehabkost@redhat.com> (raw)
Message-ID: <20190422234740.BqmeoBGuwkeIJtCcgolH677onKxl5YHyRTbVYLXbLbc@z> (raw)

Currently, libvirt uses the "filtered-features" QOM property at
runtime to ensure no feature was accidentally disabled on VCPUs
because it's not available on the host.

However, the code for "feature-words" assumes that all missing
features have a corresponding CPUID bit, which is not true for
MSR-based features like the ones at FEAT_ARCH_CAPABILITIES.

We could extend X86CPUFeatureWordInfo to include information
about MSR features, but it's impossible to do that while keeping
compatibility with clients that (reasonably) expect all elements
of "filtered-features" to have the cpuid-* fields.

We have a field in "query-cpu-definitions" that already describes
all features that are missing on a CPU, including MSR features:
CpuDefinitionInfo.unavailable-features.  The existing code for
building the unavailable-features array even uses
X86CPU::filtered_features to build the feature list.

This series adds a "unavailable-features" QOM property to X86CPU
objects that have the same semantics of "unavailable-features" on
query-cpu-definitions.  The new property has the same goal of
"filtered-features", but is generic enough to let any kind of CPU
feature to be listed there without relying on low level details
like CPUID leaves or MSR numbers.

Eduardo Habkost (2):
  i386: x86_cpu_list_feature_names() function
  i386: "unavailable-features" QOM property

 target/i386/cpu.c | 55 ++++++++++++++++++++++++++++++++++++-----------
 1 file changed, 42 insertions(+), 13 deletions(-)

-- 
2.18.0.rc1.1.g3f1ff2140



             reply	other threads:[~2019-04-22 23:55 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-22 23:47 Eduardo Habkost [this message]
2019-04-22 23:47 ` [Qemu-devel] [PATCH 0/2] i386: "unavailable-features" QOM property 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

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=20190422234742.15780-1-ehabkost@redhat.com \
    --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.