From: Glauber Costa <glommer@redhat.com>
To: kvm@vger.kernel.org
Cc: mtosatti@redhat.com, qemu-devel@nongnu.org, avi@redhat.com
Subject: [Qemu-devel] [PATCH 1/3] use kernel-provided para_features instead of statically coming up with new capabilities
Date: Thu, 17 Mar 2011 19:42:05 -0300 [thread overview]
Message-ID: <1300401727-5235-2-git-send-email-glommer@redhat.com> (raw)
In-Reply-To: <1300401727-5235-1-git-send-email-glommer@redhat.com>
According to Avi's comments over my last submission, I decided to take a
different, and more correct direction - we hope.
This patch is now using the features provided by KVM_GET_SUPPORTED_CPUID directly to
mask out features from guest-visible cpuid.
The old get_para_features() mechanism is kept for older kernels that do not implement it.
Signed-off-by: Glauber Costa <glommer@redhat.com>
---
target-i386/kvm.c | 76 +++++++++++++++++++++++++++++++---------------------
1 files changed, 45 insertions(+), 31 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index da757fa..dc1e547 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -95,6 +95,35 @@ static struct kvm_cpuid2 *try_get_cpuid(KVMState *s, int max)
return cpuid;
}
+#ifdef CONFIG_KVM_PARA
+struct kvm_para_features {
+ int cap;
+ int feature;
+} para_features[] = {
+ { KVM_CAP_CLOCKSOURCE, KVM_FEATURE_CLOCKSOURCE },
+ { KVM_CAP_NOP_IO_DELAY, KVM_FEATURE_NOP_IO_DELAY },
+ { KVM_CAP_PV_MMU, KVM_FEATURE_MMU_OP },
+#ifdef KVM_CAP_ASYNC_PF
+ { KVM_CAP_ASYNC_PF, KVM_FEATURE_ASYNC_PF },
+#endif
+ { -1, -1 }
+};
+
+static int get_para_features(CPUState *env)
+{
+ int i, features = 0;
+
+ for (i = 0; i < ARRAY_SIZE(para_features) - 1; i++) {
+ if (kvm_check_extension(env->kvm_state, para_features[i].cap)) {
+ features |= (1 << para_features[i].feature);
+ }
+ }
+
+ return features;
+}
+#endif
+
+
uint32_t kvm_arch_get_supported_cpuid(CPUState *env, uint32_t function,
uint32_t index, int reg)
{
@@ -102,6 +131,7 @@ uint32_t kvm_arch_get_supported_cpuid(CPUState *env, uint32_t function,
int i, max;
uint32_t ret = 0;
uint32_t cpuid_1_edx;
+ int has_kvm_features = 0;
max = 1;
while ((cpuid = try_get_cpuid(env->kvm_state, max)) == NULL) {
@@ -111,6 +141,9 @@ uint32_t kvm_arch_get_supported_cpuid(CPUState *env, uint32_t function,
for (i = 0; i < cpuid->nent; ++i) {
if (cpuid->entries[i].function == function &&
cpuid->entries[i].index == index) {
+ if (cpuid->entries[i].function == KVM_CPUID_FEATURES) {
+ has_kvm_features = 1;
+ }
switch (reg) {
case R_EAX:
ret = cpuid->entries[i].eax;
@@ -141,41 +174,16 @@ uint32_t kvm_arch_get_supported_cpuid(CPUState *env, uint32_t function,
}
}
+ /* fallback for older kernels */
+ if (!has_kvm_features && (function == KVM_CPUID_FEATURES)) {
+ ret = get_para_features(env);
+ }
+
qemu_free(cpuid);
return ret;
}
-#ifdef CONFIG_KVM_PARA
-struct kvm_para_features {
- int cap;
- int feature;
-} para_features[] = {
- { KVM_CAP_CLOCKSOURCE, KVM_FEATURE_CLOCKSOURCE },
- { KVM_CAP_NOP_IO_DELAY, KVM_FEATURE_NOP_IO_DELAY },
- { KVM_CAP_PV_MMU, KVM_FEATURE_MMU_OP },
-#ifdef KVM_CAP_ASYNC_PF
- { KVM_CAP_ASYNC_PF, KVM_FEATURE_ASYNC_PF },
-#endif
- { -1, -1 }
-};
-
-static int get_para_features(CPUState *env)
-{
- int i, features = 0;
-
- for (i = 0; i < ARRAY_SIZE(para_features) - 1; i++) {
- if (kvm_check_extension(env->kvm_state, para_features[i].cap)) {
- features |= (1 << para_features[i].feature);
- }
- }
-#ifdef KVM_CAP_ASYNC_PF
- has_msr_async_pf_en = features & (1 << KVM_FEATURE_ASYNC_PF);
-#endif
- return features;
-}
-#endif
-
#ifdef KVM_CAP_MCE
static int kvm_get_mce_cap_supported(KVMState *s, uint64_t *mce_cap,
int *max_banks)
@@ -363,7 +371,13 @@ int kvm_arch_init_vcpu(CPUState *env)
c = &cpuid_data.entries[cpuid_i++];
memset(c, 0, sizeof(*c));
c->function = KVM_CPUID_FEATURES;
- c->eax = env->cpuid_kvm_features & get_para_features(env);
+ c->eax = env->cpuid_kvm_features & kvm_arch_get_supported_cpuid(env,
+ KVM_CPUID_FEATURES, 0, R_EAX);
+
+#ifdef KVM_CAP_ASYNC_PF
+ has_msr_async_pf_en = c->eax & (1 << KVM_FEATURE_ASYNC_PF);
+#endif
+
#endif
cpu_x86_cpuid(env, 0, 0, &limit, &unused, &unused, &unused);
--
1.7.2.3
next prev parent reply other threads:[~2011-03-17 22:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-17 22:42 [Qemu-devel] [PATCH 0/3] enable newer msr set for kvm Glauber Costa
2011-03-17 22:42 ` Glauber Costa [this message]
2011-03-24 10:27 ` [Qemu-devel] Re: [PATCH 1/3] use kernel-provided para_features instead of statically coming up with new capabilities Avi Kivity
2011-03-17 22:42 ` [Qemu-devel] [PATCH 2/3] add kvmclock to its second bit Glauber Costa
2011-03-17 22:42 ` [Qemu-devel] [PATCH 3/3] don't create kvmclock when one of the flags are present Glauber Costa
2011-03-18 10:24 ` [Qemu-devel] " Jan Kiszka
2011-03-18 14:29 ` Glauber Costa
2011-03-24 10:37 ` [Qemu-devel] Re: [PATCH 0/3] enable newer msr set for kvm Avi Kivity
2011-03-24 10:37 ` Avi Kivity
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=1300401727-5235-2-git-send-email-glommer@redhat.com \
--to=glommer@redhat.com \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).