All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduardo Habkost <ehabkost@redhat.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	qemu-devel@nongnu.org, Igor Mammedov <imammedo@redhat.com>
Subject: Re: [PATCH v6 10/19] i386: move eVMCS enablement to hyperv_init_vcpu()
Date: Fri, 21 May 2021 17:20:21 -0400	[thread overview]
Message-ID: <20210521212021.lsf2pzfu647ocqj3@habkost.net> (raw)
In-Reply-To: <20210422161130.652779-11-vkuznets@redhat.com>

On Thu, Apr 22, 2021 at 06:11:21PM +0200, Vitaly Kuznetsov wrote:
> hyperv_expand_features() will be called before we create vCPU so
> evmcs enablement should go away. hyperv_init_vcpu() looks like the
> right place.
> 
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> ---
>  target/i386/kvm/kvm.c | 60 ++++++++++++++++++++++++++-----------------
>  1 file changed, 37 insertions(+), 23 deletions(-)
> 
> diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
> index 6b391db7a030..a2ef2dc154a2 100644
> --- a/target/i386/kvm/kvm.c
> +++ b/target/i386/kvm/kvm.c
> @@ -962,6 +962,7 @@ static struct kvm_cpuid2 *get_supported_hv_cpuid(CPUState *cs)
>  {
>      struct kvm_cpuid2 *cpuid;
>      int max = 7; /* 0x40000000..0x40000005, 0x4000000A */
> +    int i;
>  
>      /*
>       * When the buffer is too small, KVM_GET_SUPPORTED_HV_CPUID fails with
> @@ -971,6 +972,22 @@ static struct kvm_cpuid2 *get_supported_hv_cpuid(CPUState *cs)
>      while ((cpuid = try_get_hv_cpuid(cs, max)) == NULL) {
>          max++;
>      }
> +
> +    /*
> +     * KVM_GET_SUPPORTED_HV_CPUID does not set EVMCS CPUID bit before
> +     * KVM_CAP_HYPERV_ENLIGHTENED_VMCS is enabled but we want to get the
> +     * information early, just check for the capability and set the bit
> +     * manually.
> +     */

Should we add a comment noting that this hack won't be necessary
if using the system ioctl?  I assume we still want to support
Linux < v5.11 for a while, so simply 


> +    if (kvm_check_extension(cs->kvm_state,
> +                            KVM_CAP_HYPERV_ENLIGHTENED_VMCS) > 0) {
> +        for (i = 0; i < cpuid->nent; i++) {
> +            if (cpuid->entries[i].function == HV_CPUID_ENLIGHTMENT_INFO) {
> +                cpuid->entries[i].eax |= HV_ENLIGHTENED_VMCS_RECOMMENDED;
> +            }
> +        }
> +    }
> +
>      return cpuid;
>  }
>  
> @@ -1200,24 +1217,6 @@ static int hyperv_expand_features(CPUState *cs)
>      if (!hyperv_enabled(cpu))
>          return 0;
>  
> -    if (hyperv_feat_enabled(cpu, HYPERV_FEAT_EVMCS) ||
> -        cpu->hyperv_passthrough) {
> -        uint16_t evmcs_version;
> -
> -        r = kvm_vcpu_enable_cap(cs, KVM_CAP_HYPERV_ENLIGHTENED_VMCS, 0,
> -                                (uintptr_t)&evmcs_version);
> -
> -        if (hyperv_feat_enabled(cpu, HYPERV_FEAT_EVMCS) && r) {
> -            fprintf(stderr, "Hyper-V %s is not supported by kernel\n",
> -                    kvm_hyperv_properties[HYPERV_FEAT_EVMCS].desc);
> -            return -ENOSYS;
> -        }
> -
> -        if (!r) {
> -            cpu->hyperv_nested[0] = evmcs_version;
> -        }
> -    }
> -
>      if (cpu->hyperv_passthrough) {
>          cpu->hyperv_vendor_id[0] =
>              hv_cpuid_get_host(cs, HV_CPUID_VENDOR_AND_MAX_FUNCTIONS, R_EBX);
> @@ -1455,6 +1454,21 @@ static int hyperv_init_vcpu(X86CPU *cpu)
>          }
>      }
>  
> +    if (hyperv_feat_enabled(cpu, HYPERV_FEAT_EVMCS)) {
> +        uint16_t evmcs_version;
> +
> +        ret = kvm_vcpu_enable_cap(cs, KVM_CAP_HYPERV_ENLIGHTENED_VMCS, 0,
> +                                  (uintptr_t)&evmcs_version);
> +
> +        if (ret < 0) {
> +            fprintf(stderr, "Hyper-V %s is not supported by kernel\n",
> +                    kvm_hyperv_properties[HYPERV_FEAT_EVMCS].desc);
> +            return ret;
> +        }
> +
> +        cpu->hyperv_nested[0] = evmcs_version;

Wait, won't this break guest ABI?  Do we want to make
HYPERV_FEAT_EVMCS a migration blocker until this is fixed?


> +    }
> +
>      return 0;
>  }
>  
> @@ -1519,6 +1533,11 @@ int kvm_arch_init_vcpu(CPUState *cs)
>      }
>  
>      if (hyperv_enabled(cpu)) {
> +        r = hyperv_init_vcpu(cpu);
> +        if (r) {
> +            return r;
> +        }
> +
>          cpuid_i = hyperv_fill_cpuids(cs, cpuid_data.entries);
>          kvm_base = KVM_CPUID_SIGNATURE_NEXT;
>          has_msr_hv_hypercall = true;
> @@ -1868,11 +1887,6 @@ int kvm_arch_init_vcpu(CPUState *cs)
>  
>      kvm_init_msrs(cpu);
>  
> -    r = hyperv_init_vcpu(cpu);
> -    if (r) {
> -        goto fail;
> -    }
> -
>      return 0;

I would move the two hunks above to a separate patch, but not a
big deal.  The guest ABI issue is existing, and the comment
suggestion can be done in a follow up patch, so:

Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>

>  
>   fail:
> -- 
> 2.30.2
> 

-- 
Eduardo



  reply	other threads:[~2021-05-21 21:21 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-22 16:11 [PATCH v6 00/19] i386: KVM: expand Hyper-V features early Vitaly Kuznetsov
2021-04-22 16:11 ` [PATCH v6 01/19] i386: keep hyperv_vendor string up-to-date Vitaly Kuznetsov
2021-04-30 23:07   ` Eduardo Habkost
2021-06-02 11:41     ` Vitaly Kuznetsov
2021-04-22 16:11 ` [PATCH v6 02/19] i386: invert hyperv_spinlock_attempts setting logic with hv_passthrough Vitaly Kuznetsov
2021-04-30 23:09   ` Eduardo Habkost
2021-04-22 16:11 ` [PATCH v6 03/19] i386: always fill Hyper-V CPUID feature leaves from X86CPU data Vitaly Kuznetsov
2021-04-30 23:15   ` Eduardo Habkost
2021-04-22 16:11 ` [PATCH v6 04/19] i386: stop using env->features[] for filling Hyper-V CPUIDs Vitaly Kuznetsov
2021-05-01  0:34   ` Eduardo Habkost
2021-05-20 19:49     ` Eduardo Habkost
2021-05-21  7:54       ` Vitaly Kuznetsov
2021-04-22 16:11 ` [PATCH v6 05/19] i386: introduce hyperv_feature_supported() Vitaly Kuznetsov
2021-05-20 19:53   ` Eduardo Habkost
2021-05-21  7:57     ` Vitaly Kuznetsov
2021-04-22 16:11 ` [PATCH v6 06/19] i386: introduce hv_cpuid_get_host() Vitaly Kuznetsov
2021-05-20 20:01   ` Eduardo Habkost
2021-05-21  7:57     ` Vitaly Kuznetsov
2021-04-22 16:11 ` [PATCH v6 07/19] i386: drop FEAT_HYPERV feature leaves Vitaly Kuznetsov
2021-05-20 20:13   ` Eduardo Habkost
2021-04-22 16:11 ` [PATCH v6 08/19] i386: introduce hv_cpuid_cache Vitaly Kuznetsov
2021-05-20 20:16   ` Eduardo Habkost
2021-04-22 16:11 ` [PATCH v6 09/19] i386: split hyperv_handle_properties() into hyperv_expand_features()/hyperv_fill_cpuids() Vitaly Kuznetsov
2021-05-20 21:34   ` Eduardo Habkost
2021-04-22 16:11 ` [PATCH v6 10/19] i386: move eVMCS enablement to hyperv_init_vcpu() Vitaly Kuznetsov
2021-05-21 21:20   ` Eduardo Habkost [this message]
2021-05-24 12:00     ` Vitaly Kuznetsov
2021-05-26 16:35       ` Eduardo Habkost
2021-05-27  7:27         ` Vitaly Kuznetsov
2021-05-27 19:16           ` Eduardo Habkost
2021-04-22 16:11 ` [PATCH v6 11/19] i386: switch hyperv_expand_features() to using error_setg() Vitaly Kuznetsov
2021-05-21 21:37   ` Eduardo Habkost
2021-05-24 12:05     ` Vitaly Kuznetsov
2021-04-22 16:11 ` [PATCH v6 12/19] i386: adjust the expected KVM_GET_SUPPORTED_HV_CPUID array size Vitaly Kuznetsov
2021-05-21 21:37   ` Eduardo Habkost
2021-04-22 16:11 ` [PATCH v6 13/19] i386: prefer system KVM_GET_SUPPORTED_HV_CPUID ioctl over vCPU's one Vitaly Kuznetsov
2021-05-21 21:42   ` Eduardo Habkost
2021-05-24 12:08     ` Vitaly Kuznetsov
2021-05-26 16:46       ` Eduardo Habkost
2021-05-26 16:56         ` Daniel P. Berrangé
2021-04-22 16:11 ` [PATCH v6 14/19] i386: use global kvm_state in hyperv_enabled() check Vitaly Kuznetsov
2021-05-21 21:42   ` Eduardo Habkost
2021-04-22 16:11 ` [PATCH v6 15/19] i386: expand Hyper-V features during CPU feature expansion time Vitaly Kuznetsov
2021-05-21 21:45   ` Eduardo Habkost
2021-05-24 12:13     ` Vitaly Kuznetsov
2021-05-26 16:57       ` Eduardo Habkost
2021-05-27  7:29         ` Vitaly Kuznetsov
2021-04-22 16:11 ` [PATCH v6 16/19] i386: kill off hv_cpuid_check_and_set() Vitaly Kuznetsov
2021-05-21 21:56   ` Eduardo Habkost
2021-05-24 12:13     ` Vitaly Kuznetsov
2021-04-22 16:11 ` [PATCH v6 17/19] i386: HV_HYPERCALL_AVAILABLE privilege bit is always needed Vitaly Kuznetsov
2021-05-21 22:06   ` Eduardo Habkost
2021-05-24 12:22     ` Vitaly Kuznetsov
2021-05-26 17:05       ` Eduardo Habkost
2021-05-27  7:37         ` Vitaly Kuznetsov
2021-05-27 19:34           ` Eduardo Habkost
2021-04-22 16:11 ` [PATCH v6 18/19] i386: Hyper-V SynIC requires POST_MESSAGES/SIGNAL_EVENTS priviliges Vitaly Kuznetsov
2021-04-22 16:11 ` [PATCH v6 19/19] qtest/hyperv: Introduce a simple hyper-v test Vitaly Kuznetsov
2021-05-26 20:20 ` [PATCH v6 00/19] i386: KVM: expand Hyper-V features early Eduardo Habkost
2021-05-27  7:39   ` Vitaly Kuznetsov
2021-05-27 19:35     ` 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=20210521212021.lsf2pzfu647ocqj3@habkost.net \
    --to=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=vkuznets@redhat.com \
    /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.