qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Glauber Costa <glommer@redhat.com>
Cc: mtosatti@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: [Qemu-devel] Re: [PATCH 1/3] use kernel-provided para_features instead of statically coming up with new capabilities
Date: Thu, 24 Mar 2011 12:27:27 +0200	[thread overview]
Message-ID: <4D8B1C8F.7060302@redhat.com> (raw)
In-Reply-To: <1300401727-5235-2-git-send-email-glommer@redhat.com>

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

  reply	other threads:[~2011-03-24 10:27 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 ` [Qemu-devel] [PATCH 1/3] use kernel-provided para_features instead of statically coming up with new capabilities Glauber Costa
2011-03-24 10:27   ` Avi Kivity [this message]
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=4D8B1C8F.7060302@redhat.com \
    --to=avi@redhat.com \
    --cc=glommer@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).