From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Eduardo Habkost <ehabkost@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 v7 3/9] i386: hardcode supported eVMCS version to '1'
Date: Fri, 04 Jun 2021 09:28:15 +0200 [thread overview]
Message-ID: <877dja1434.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <20210603223506.no7j7jais3qixdhs@habkost.net>
Eduardo Habkost <ehabkost@redhat.com> writes:
> On Thu, Jun 03, 2021 at 01:48:29PM +0200, Vitaly Kuznetsov wrote:
>> Currently, the only eVMCS version, supported by KVM (and described in TLFS)
>> is '1'. When Enlightened VMCS feature is enabled, QEMU takes the supported
>> eVMCS version range (from KVM_CAP_HYPERV_ENLIGHTENED_VMCS enablement) and
>> puts it to guest visible CPUIDs. When (and if) eVMCS ver.2 appears a
>> problem on migration is expected: it doesn't seem to be possible to migrate
>> from a host supporting eVMCS ver.2 to a host, which only support eVMCS
>> ver.1.
>
> Isn't it possible and safe to expose eVMCS ver.1 to the guest on
> a host that supports ver.2?
We expose the supported range, guest is free to use any eVMCS version in
the range (see below):
>
>>
>> Hardcode eVMCS ver.1 as the result of 'hv-evmcs' enablement for now. Newer
>> eVMCS versions will have to have their own enablement options (e.g.
>> 'hv-evmcs=2').
>>
>> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>> ---
>> docs/hyperv.txt | 2 +-
>> target/i386/kvm/kvm.c | 16 +++++++++++-----
>> 2 files changed, 12 insertions(+), 6 deletions(-)
>>
>> diff --git a/docs/hyperv.txt b/docs/hyperv.txt
>> index a51953daa833..000638a2fd38 100644
>> --- a/docs/hyperv.txt
>> +++ b/docs/hyperv.txt
>> @@ -170,7 +170,7 @@ Recommended: hv-frequencies
>> 3.16. hv-evmcs
>> ===============
>> The enlightenment is nested specific, it targets Hyper-V on KVM guests. When
>> -enabled, it provides Enlightened VMCS feature to the guest. The feature
>> +enabled, it provides Enlightened VMCS version 1 feature to the guest. The feature
>> implements paravirtualized protocol between L0 (KVM) and L1 (Hyper-V)
>> hypervisors making L2 exits to the hypervisor faster. The feature is Intel-only.
>> Note: some virtualization features (e.g. Posted Interrupts) are disabled when
>> diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
>> index c676ee8b38a7..d57eede5dc81 100644
>> --- a/target/i386/kvm/kvm.c
>> +++ b/target/i386/kvm/kvm.c
>> @@ -1490,13 +1490,19 @@ static int hyperv_init_vcpu(X86CPU *cpu)
>> 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);
>> + /*
>> + * KVM is required to support EVMCS ver.1. as that's what 'hv-evmcs'
>> + * option sets. Note: we hardcode the maximum supported eVMCS version
>> + * to '1' as well so 'hv-evmcs' feature is migratable even when (and if)
>> + * ver.2 is implemented. A new option (e.g. 'hv-evmcs=2') will then have
>> + * to be added.
>> + */
>> + if (ret < 0 || (uint8_t)evmcs_version > 1) {
>
> Wait, do you really want to get a fatal error every time, after a
> kernel upgrade?
>
Here, evmcs_version (returned by kvm_vcpu_enable_cap()) represents a
*range* of supported eVMCS versions:
(evmcs_highest_supported_version << 8) | evmcs_lowest_supported_version
Currently, this is 0x101 [1..1] range.
The '(uint8_t)evmcs_version > 1' check here means 'eVMCS v1' is no
longer supported by KVM. This is not going to happen any time soon, but
I can imagine in 10 years or so we'll be dropping v1 so the range (in
theory) can be [10..2] -- which would mean eVMCS ver. 1 is NOT
supported. And we can't proceed then.
> I was expecting this:
>
> vcpu_evmcs_version = 1; /* hardcoded, but can become configurable later */
> ...
> kvm_vcpu_enable_cap(cs, KVM_CAP_HYPERV_ENLIGHTENED_VMCS, 0, (uintptr_t)&supported_evmcs_version);
> if (ret < 0 || supported_evmcs_version < vcpu_evmcs_version) {
> error_setg(...);
> return;
> }
> cpu->hyperv_nested[0] = vcpu_evmcs_version;
>
>
>> + error_report("Hyper-V %s verson 1 is not supported by kernel",
>> + kvm_hyperv_properties[HYPERV_FEAT_EVMCS].desc);
>> return ret;
>> }
>> -
>> - cpu->hyperv_nested[0] = evmcs_version;
>> + cpu->hyperv_nested[0] = (1 << 8) | 1;
>> }
>>
>> return 0;
>> --
>> 2.31.1
>>
--
Vitaly
next prev parent reply other threads:[~2021-06-04 7:29 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-03 11:48 [PATCH v7 0/9] i386: KVM: expand Hyper-V features early Vitaly Kuznetsov
2021-06-03 11:48 ` [PATCH v7 1/9] i386: avoid hardcoding '12' as 'hyperv_vendor_id' length Vitaly Kuznetsov
2021-06-03 22:27 ` Eduardo Habkost
2021-07-08 20:57 ` Eduardo Habkost
2021-06-03 11:48 ` [PATCH v7 2/9] i386: clarify 'hv-passthrough' behavior Vitaly Kuznetsov
2021-06-03 22:28 ` Eduardo Habkost
2021-06-03 11:48 ` [PATCH v7 3/9] i386: hardcode supported eVMCS version to '1' Vitaly Kuznetsov
2021-06-03 22:35 ` Eduardo Habkost
2021-06-04 7:28 ` Vitaly Kuznetsov [this message]
2021-06-04 19:00 ` Eduardo Habkost
2021-06-07 8:38 ` Vitaly Kuznetsov
2021-06-03 11:48 ` [PATCH v7 4/9] i386: make hyperv_expand_features() return bool Vitaly Kuznetsov
2021-06-03 22:39 ` Eduardo Habkost
2021-06-03 11:48 ` [PATCH v7 5/9] i386: expand Hyper-V features during CPU feature expansion time Vitaly Kuznetsov
2021-06-03 22:43 ` Eduardo Habkost
2021-06-04 7:31 ` Vitaly Kuznetsov
2021-06-03 11:48 ` [PATCH v7 6/9] i386: kill off hv_cpuid_check_and_set() Vitaly Kuznetsov
2021-06-03 11:48 ` [PATCH v7 7/9] i386: HV_HYPERCALL_AVAILABLE privilege bit is always needed Vitaly Kuznetsov
2021-06-03 22:43 ` Eduardo Habkost
2021-06-03 11:48 ` [PATCH v7 8/9] i386: Hyper-V SynIC requires POST_MESSAGES/SIGNAL_EVENTS priviliges Vitaly Kuznetsov
2021-06-03 23:00 ` Eduardo Habkost
2021-06-04 7:35 ` Vitaly Kuznetsov
2021-06-07 16:45 ` Eduardo Habkost
2021-06-04 14:06 ` Eric Blake
2021-06-03 11:48 ` [PATCH v7 9/9] qtest/hyperv: Introduce a simple hyper-v test Vitaly Kuznetsov
2021-06-03 23:17 ` Eduardo Habkost
2021-06-04 7:40 ` Vitaly Kuznetsov
2021-07-07 13:59 ` [PATCH v7 0/9] i386: KVM: expand Hyper-V features early 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=877dja1434.fsf@vitty.brq.redhat.com \
--to=vkuznets@redhat.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@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 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.