[Qemu-devel] [PATCH 0/3] enable newer msr set for kvm

[Qemu-devel] [PATCH 0/3] enable newer msr set for kvm

[Glauber Costa]

This patch is a follow up to an earlier one that aims to enable
kvmclock newer msr set. This time I'm doing it through a more sane
mechanism of consulting the kernel about the supported msr set.

Glauber Costa (3):
  use kernel-provided para_features instead of statically coming up
    with new capabilities
  add kvmclock to its second bit
  don't create kvmclock when one of the flags are present.

 hw/kvmclock.c       |    6 +++-
 target-i386/cpuid.c |    3 +-
 target-i386/kvm.c   |   76 ++++++++++++++++++++++++++++++---------------------
 3 files changed, 51 insertions(+), 34 deletions(-)

-- 
1.7.2.3

[Qemu-devel] [PATCH 1/3] use kernel-provided para_features instead of statically coming up with new capabilities

[Glauber Costa]

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

[Qemu-devel] Re: [PATCH 1/3] use kernel-provided para_features instead of statically coming up with new capabilities

[Avi Kivity]

On 03/18/2011 12:42 AM, Glauber Costa wrote:
> 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.
>
>
>
> +#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

Shouldn't the others get the same #ifdef treatment?

Yes, we depend on a kernels of a certain age, but let's not add more 
dependencies.

> +    { -1, -1 }
> +};

Since you use ARRAY_SIZE() later, don't need the guard here.

> +
> +static int get_para_features(CPUState *env)
> +{
> +    int i, features = 0;
> +
> +    for (i = 0; i<  ARRAY_SIZE(para_features) - 1; i++) {

So you can drop the - 1.

> +        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)
>   {
>
>
> -#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
> -

Oh.  The whole thing was copied wholesale.  Nevermind.

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] [PATCH 2/3] add kvmclock to its second bit

[Glauber Costa]

We have two bits that can represent kvmclock in cpuid.
They signal the guest which msr set to use. When we tweak flags
involving this value - specially when we use "-", we have to act on both.

Besides adding it to the kvm features list, we also have to "break" the
assumption represented by the break in lookup_feature.

Signed-off-by: Glauber Costa <glommer@redhat.com>
---
 target-i386/cpuid.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/target-i386/cpuid.c b/target-i386/cpuid.c
index d28de20..48f9bbd 100644
--- a/target-i386/cpuid.c
+++ b/target-i386/cpuid.c
@@ -73,7 +73,7 @@ static const char *ext3_feature_name[] = {
 };
 
 static const char *kvm_feature_name[] = {
-    "kvmclock", "kvm_nopiodelay", "kvm_mmu", NULL, "kvm_asyncpf", NULL, NULL, NULL,
+    "kvmclock", "kvm_nopiodelay", "kvm_mmu", "kvmclock", "kvm_asyncpf", NULL, NULL, NULL,
     NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
     NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
     NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
@@ -193,7 +193,6 @@ static int lookup_feature(uint32_t *pval, const char *s, const char *e,
     for (mask = 1, ppc = featureset; mask; mask <<= 1, ++ppc)
         if (*ppc && !altcmp(s, e, *ppc)) {
             *pval |= mask;
-            break;
         }
     return (mask ? 1 : 0);
 }
-- 
1.7.2.3

[Qemu-devel] [PATCH 3/3] don't create kvmclock when one of the flags are present.

[Glauber Costa]

kvmclock presence can be signalled by two different flags. So for
device creation, we have to test for both.

Signed-off-by: Glauber Costa <glommer@redhat.com>
---
 hw/kvmclock.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/hw/kvmclock.c b/hw/kvmclock.c
index b6ceddf..004c4ad 100644
--- a/hw/kvmclock.c
+++ b/hw/kvmclock.c
@@ -103,7 +103,11 @@ static SysBusDeviceInfo kvmclock_info = {
 void kvmclock_create(void)
 {
     if (kvm_enabled() &&
-        first_cpu->cpuid_kvm_features & (1ULL << KVM_FEATURE_CLOCKSOURCE)) {
+        first_cpu->cpuid_kvm_features & ((1ULL << KVM_FEATURE_CLOCKSOURCE)
+#ifdef KVM_FEATURE_CLOCKSOURCE2
+        || (1ULL << KVM_FEATURE_CLOCKSOURCE2)
+#endif
+    )) {
         sysbus_create_simple("kvmclock", -1, NULL);
     }
 }
-- 
1.7.2.3

[Qemu-devel] Re: [PATCH 3/3] don't create kvmclock when one of the flags are present.

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 974 bytes --]

On 2011-03-17 23:42, Glauber Costa wrote:
> kvmclock presence can be signalled by two different flags. So for
> device creation, we have to test for both.

Patch is OK, but the subject's logic is inverted.

Jan

> 
> Signed-off-by: Glauber Costa <glommer@redhat.com>
> ---
>  hw/kvmclock.c |    6 +++++-
>  1 files changed, 5 insertions(+), 1 deletions(-)
> 
> diff --git a/hw/kvmclock.c b/hw/kvmclock.c
> index b6ceddf..004c4ad 100644
> --- a/hw/kvmclock.c
> +++ b/hw/kvmclock.c
> @@ -103,7 +103,11 @@ static SysBusDeviceInfo kvmclock_info = {
>  void kvmclock_create(void)
>  {
>      if (kvm_enabled() &&
> -        first_cpu->cpuid_kvm_features & (1ULL << KVM_FEATURE_CLOCKSOURCE)) {
> +        first_cpu->cpuid_kvm_features & ((1ULL << KVM_FEATURE_CLOCKSOURCE)
> +#ifdef KVM_FEATURE_CLOCKSOURCE2
> +        || (1ULL << KVM_FEATURE_CLOCKSOURCE2)
> +#endif
> +    )) {
>          sysbus_create_simple("kvmclock", -1, NULL);
>      }
>  }


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

[Qemu-devel] Re: [PATCH 3/3] don't create kvmclock when one of the flags are present.

[Glauber Costa]

On Fri, 2011-03-18 at 11:24 +0100, Jan Kiszka wrote:
> On 2011-03-17 23:42, Glauber Costa wrote:
> > kvmclock presence can be signalled by two different flags. So for
> > device creation, we have to test for both.

> Patch is OK, but the subject's logic is inverted.
Indeed, should have said something like "to test for either of them"

Dear maintainers, is it okay to commit with a minor edit to the
changelogs?

> Jan
> 
> > 
> > Signed-off-by: Glauber Costa <glommer@redhat.com>
> > ---
> >  hw/kvmclock.c |    6 +++++-
> >  1 files changed, 5 insertions(+), 1 deletions(-)
> > 
> > diff --git a/hw/kvmclock.c b/hw/kvmclock.c
> > index b6ceddf..004c4ad 100644
> > --- a/hw/kvmclock.c
> > +++ b/hw/kvmclock.c
> > @@ -103,7 +103,11 @@ static SysBusDeviceInfo kvmclock_info = {
> >  void kvmclock_create(void)
> >  {
> >      if (kvm_enabled() &&
> > -        first_cpu->cpuid_kvm_features & (1ULL << KVM_FEATURE_CLOCKSOURCE)) {
> > +        first_cpu->cpuid_kvm_features & ((1ULL << KVM_FEATURE_CLOCKSOURCE)
> > +#ifdef KVM_FEATURE_CLOCKSOURCE2
> > +        || (1ULL << KVM_FEATURE_CLOCKSOURCE2)
> > +#endif
> > +    )) {
> >          sysbus_create_simple("kvmclock", -1, NULL);
> >      }
> >  }
> 

[Qemu-devel] Re: [PATCH 0/3] enable newer msr set for kvm

[Avi Kivity]

On 03/18/2011 12:42 AM, Glauber Costa wrote:
> This patch is a follow up to an earlier one that aims to enable
> kvmclock newer msr set. This time I'm doing it through a more sane
> mechanism of consulting the kernel about the supported msr set.

Thanks, applied.

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] Re: [PATCH 0/3] enable newer msr set for kvm

[Avi Kivity]

On 03/24/2011 12:37 PM, Avi Kivity wrote:
> On 03/18/2011 12:42 AM, Glauber Costa wrote:
>> This patch is a follow up to an earlier one that aims to enable
>> kvmclock newer msr set. This time I'm doing it through a more sane
>> mechanism of consulting the kernel about the supported msr set.
>
> Thanks, applied.
>

(to uq/master)

-- 
error compiling committee.c: too many arguments to function