From: Igor Mammedov <imammedo@redhat.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
qemu-devel@nongnu.org, Eduardo Habkost <ehabkost@redhat.com>
Subject: Re: [PATCH v3 18/19] i386: provide simple 'hv-default=on' option
Date: Fri, 15 Jan 2021 03:11:42 +0100 [thread overview]
Message-ID: <20210115031142.7c171a7f@redhat.com> (raw)
In-Reply-To: <20210107151449.541062-1-vkuznets@redhat.com>
On Thu, 7 Jan 2021 16:14:49 +0100
Vitaly Kuznetsov <vkuznets@redhat.com> wrote:
> Enabling Hyper-V emulation for a Windows VM is a tiring experience as it
> requires listing all currently supported enlightenments ("hv-*" CPU
> features) explicitly. We do have 'hv-passthrough' mode enabling
> everything but it can't be used in production as it prevents migration.
>
> Introduce a simple 'hv-default=on' CPU flag enabling all currently supported
> Hyper-V enlightenments. Later, when new enlightenments get implemented,
> compat_props mechanism will be used to disable them for legacy machine types,
> this will keep 'hv-default=on' configurations migratable.
>
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> ---
> docs/hyperv.txt | 16 +++++++++++++---
> target/i386/cpu.c | 38 ++++++++++++++++++++++++++++++++++++++
> target/i386/cpu.h | 5 +++++
> 3 files changed, 56 insertions(+), 3 deletions(-)
>
> diff --git a/docs/hyperv.txt b/docs/hyperv.txt
> index 5df00da54fc4..a54c066cab09 100644
> --- a/docs/hyperv.txt
> +++ b/docs/hyperv.txt
> @@ -17,10 +17,20 @@ compatible hypervisor and use Hyper-V specific features.
>
> 2. Setup
> =========
> -No Hyper-V enlightenments are enabled by default by either KVM or QEMU. In
> -QEMU, individual enlightenments can be enabled through CPU flags, e.g:
> +All currently supported Hyper-V enlightenments can be enabled by specifying
> +'hv-default=on' CPU flag:
>
> - qemu-system-x86_64 --enable-kvm --cpu host,hv_relaxed,hv_vpindex,hv_time, ...
> + qemu-system-x86_64 --enable-kvm --cpu host,hv-default ...
> +
> +Alternatively, it is possible to do fine-grained enablement through CPU flags,
> +e.g:
> +
> + qemu-system-x86_64 --enable-kvm --cpu host,hv-relaxed,hv-vpindex,hv-time ...
I'd put here not '...' but rather recommended list of flags, and update
it every time when new feature added if necessary.
(not to mention that if we had it to begin with, then new 'hv-default' won't
be necessary, I still see it as functionality duplication but I will not oppose it)
> +It is also possible to disable individual enlightenments from the default list,
> +this can be used for debugging purposes:
> +
> + qemu-system-x86_64 --enable-kvm --cpu host,hv-default=on,hv-evmcs=off ...
>
> Sometimes there are dependencies between enlightenments, QEMU is supposed to
> check that the supplied configuration is sane.
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 48007a876e32..99338de00f78 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -4552,6 +4552,24 @@ static void x86_cpuid_set_tsc_freq(Object *obj, Visitor *v, const char *name,
> cpu->env.tsc_khz = cpu->env.user_tsc_khz = value / 1000;
> }
>
> +static bool x86_hv_default_get(Object *obj, Error **errp)
> +{
> + X86CPU *cpu = X86_CPU(obj);
> +
> + return cpu->hyperv_default;
> +}
> +
> +static void x86_hv_default_set(Object *obj, bool value, Error **errp)
> +{
> + X86CPU *cpu = X86_CPU(obj);
> +
> + cpu->hyperv_default = value;
> +
> + if (value) {
> + cpu->hyperv_features |= cpu->hyperv_default_features;
s/|="/=/ please,
i.e. no option overrides whatever was specified before to keep semantics consistent.
> + }
> +}
> +
> /* Generic getter for "feature-words" and "filtered-features" properties */
> static void x86_cpu_get_feature_words(Object *obj, Visitor *v,
> const char *name, void *opaque,
> @@ -6955,10 +6973,26 @@ static void x86_cpu_initfn(Object *obj)
> object_property_add_alias(obj, "pause_filter", obj, "pause-filter");
> object_property_add_alias(obj, "sse4_1", obj, "sse4.1");
> object_property_add_alias(obj, "sse4_2", obj, "sse4.2");
> + object_property_add_alias(obj, "hv_default", obj, "hv-default");
>
> if (xcc->model) {
> x86_cpu_load_model(cpu, xcc->model);
> }
> +
> + /* Hyper-V features enabled with 'hv-default=on' */
> + cpu->hyperv_default_features = BIT(HYPERV_FEAT_RELAXED) |
> + BIT(HYPERV_FEAT_VAPIC) | BIT(HYPERV_FEAT_TIME) |
> + BIT(HYPERV_FEAT_CRASH) | BIT(HYPERV_FEAT_RESET) |
> + BIT(HYPERV_FEAT_VPINDEX) | BIT(HYPERV_FEAT_RUNTIME) |
> + BIT(HYPERV_FEAT_SYNIC) | BIT(HYPERV_FEAT_STIMER) |
> + BIT(HYPERV_FEAT_FREQUENCIES) | BIT(HYPERV_FEAT_REENLIGHTENMENT) |
> + BIT(HYPERV_FEAT_TLBFLUSH) | BIT(HYPERV_FEAT_IPI) |
> + BIT(HYPERV_FEAT_STIMER_DIRECT);
> +
> + /* Enlightened VMCS is only available on Intel/VMX */
> + if (kvm_hv_evmcs_available()) {
> + cpu->hyperv_default_features |= BIT(HYPERV_FEAT_EVMCS);
> + }
what if VVM is migrated to another host without evmcs,
will it change CPUID?
> }
>
> static int64_t x86_cpu_get_arch_id(CPUState *cs)
> @@ -7285,6 +7319,10 @@ static void x86_cpu_common_class_init(ObjectClass *oc, void *data)
> x86_cpu_get_crash_info_qom, NULL, NULL, NULL);
> #endif
>
> + object_class_property_add_bool(oc, "hv-default",
> + x86_hv_default_get,
> + x86_hv_default_set);
> +
> for (w = 0; w < FEATURE_WORDS; w++) {
> int bitnr;
> for (bitnr = 0; bitnr < 64; bitnr++) {
> diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> index 6220cb2cabb9..8a484becb6b9 100644
> --- a/target/i386/cpu.h
> +++ b/target/i386/cpu.h
> @@ -1657,6 +1657,11 @@ struct X86CPU {
> bool hyperv_synic_kvm_only;
> uint64_t hyperv_features;
> bool hyperv_passthrough;
> +
> + /* 'hv-default' enablement */
> + uint64_t hyperv_default_features;
> + bool hyperv_default;
> +
> OnOffAuto hyperv_no_nonarch_cs;
> uint32_t hyperv_vendor_id[3];
> uint32_t hyperv_interface_id[4];
next prev parent reply other threads:[~2021-01-15 2:12 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-07 15:06 [PATCH v3 00/19] i386: KVM: expand Hyper-V features early and provide simple 'hv-default=on' option Vitaly Kuznetsov
2021-01-07 15:06 ` [PATCH v3 01/19] linux-headers: update against 5.11-rc2 Vitaly Kuznetsov
2021-01-07 15:06 ` [PATCH v3 02/19] i386: introduce kvm_hv_evmcs_available() Vitaly Kuznetsov
2021-01-07 15:06 ` [PATCH v3 03/19] i386: keep hyperv_vendor string up-to-date Vitaly Kuznetsov
2021-01-07 15:06 ` [PATCH v3 04/19] i386: invert hyperv_spinlock_attempts setting logic with hv_passthrough Vitaly Kuznetsov
2021-01-07 15:06 ` [PATCH v3 05/19] i386: always fill Hyper-V CPUID feature leaves from X86CPU data Vitaly Kuznetsov
2021-01-07 15:06 ` [PATCH v3 06/19] i386: stop using env->features[] for filling Hyper-V CPUIDs Vitaly Kuznetsov
2021-01-07 15:06 ` [PATCH v3 07/19] i386: introduce hyperv_feature_supported() Vitaly Kuznetsov
2021-01-07 15:06 ` [PATCH v3 08/19] i386: introduce hv_cpuid_get_host() Vitaly Kuznetsov
2021-01-07 15:14 ` [PATCH v3 09/19] i386: drop FEAT_HYPERV feature leaves Vitaly Kuznetsov
2021-01-07 15:14 ` [PATCH v3 10/19] i386: introduce hv_cpuid_cache Vitaly Kuznetsov
2021-01-07 15:14 ` [PATCH v3 11/19] i386: split hyperv_handle_properties() into hyperv_expand_features()/hyperv_fill_cpuids() Vitaly Kuznetsov
2021-01-07 15:14 ` [PATCH v3 12/19] i386: move eVMCS enablement to hyperv_init_vcpu() Vitaly Kuznetsov
2021-01-07 15:14 ` [PATCH v3 13/19] i386: switch hyperv_expand_features() to using error_setg() Vitaly Kuznetsov
2021-01-07 15:14 ` [PATCH v3 14/19] i386: adjust the expected KVM_GET_SUPPORTED_HV_CPUID array size Vitaly Kuznetsov
2021-01-07 15:14 ` [PATCH v3 15/19] i386: prefer system KVM_GET_SUPPORTED_HV_CPUID ioctl over vCPU's one Vitaly Kuznetsov
2021-01-07 15:14 ` [PATCH v3 16/19] i386: use global kvm_state in hyperv_enabled() check Vitaly Kuznetsov
2021-01-07 15:14 ` [PATCH v3 17/19] i386: expand Hyper-V features during CPU feature expansion time Vitaly Kuznetsov
2021-01-07 15:14 ` [PATCH v3 18/19] i386: provide simple 'hv-default=on' option Vitaly Kuznetsov
2021-01-15 2:11 ` Igor Mammedov [this message]
2021-01-15 9:20 ` Vitaly Kuznetsov
2021-01-20 13:13 ` Igor Mammedov
2021-01-20 14:38 ` Vitaly Kuznetsov
2021-01-20 19:08 ` Igor Mammedov
2021-01-20 20:49 ` Eduardo Habkost
2021-01-21 13:27 ` Igor Mammedov
2021-01-21 16:23 ` Igor Mammedov
2021-01-21 17:08 ` Eduardo Habkost
2021-01-25 13:42 ` David Edmondson
2021-01-21 8:45 ` Vitaly Kuznetsov
2021-01-21 13:49 ` Igor Mammedov
2021-01-21 16:51 ` Vitaly Kuznetsov
2021-01-20 19:55 ` Eduardo Habkost
2021-01-07 15:14 ` [PATCH v3 19/19] qtest/hyperv: Introduce a simple hyper-v test Vitaly Kuznetsov
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=20210115031142.7c171a7f@redhat.com \
--to=imammedo@redhat.com \
--cc=ehabkost@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 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).