diff options
| author | Vitaly Kuznetsov <vkuznets@redhat.com> | 2021-03-19 13:38:01 +0100 |
|---|---|---|
| committer | Paolo Bonzini <pbonzini@redhat.com> | 2021-03-19 08:48:18 -0400 |
| commit | 561dbb41b1d752098249128d8462aaadc56fd15d (patch) | |
| tree | 4fb17e7a7151927deb5ff2ba78de6b7723a020e8 | |
| parent | 816d20c927a930f1ff66656a8dafd9861806c602 (diff) | |
i386: Make migration fail when Hyper-V reenlightenment was enabled but 'user_tsc_khz' is unset
KVM doesn't fully support Hyper-V reenlightenment notifications on
migration. In particular, it doesn't support emulating TSC frequency
of the source host by trapping all TSC accesses so unless TSC scaling
is supported on the destination host and KVM_SET_TSC_KHZ succeeds, it
is unsafe to proceed with migration.
KVM_SET_TSC_KHZ is called from two sites: kvm_arch_init_vcpu() and
kvm_arch_put_registers(). The later (intentionally) doesn't propagate
errors allowing migrations to succeed even when TSC scaling is not
supported on the destination. This doesn't suit 're-enlightenment'
use-case as we have to guarantee that TSC frequency stays constant.
Require 'tsc-frequency=' command line option to be specified for successful
migration when re-enlightenment was enabled by the guest.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20210319123801.1111090-1-vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
| -rw-r--r-- | docs/hyperv.txt | 5 | ||||
| -rw-r--r-- | target/i386/kvm/hyperv-proto.h | 1 | ||||
| -rw-r--r-- | target/i386/machine.c | 20 |
3 files changed, 26 insertions, 0 deletions
diff --git a/docs/hyperv.txt b/docs/hyperv.txt index 5df00da54f..e53c581f45 100644 --- a/docs/hyperv.txt +++ b/docs/hyperv.txt @@ -160,6 +160,11 @@ the hypervisor) until it is ready to switch to the new one. This, in conjunction with hv-frequencies, allows Hyper-V on KVM to pass stable clocksource (Reference TSC page) to its own guests. +Note, KVM doesn't fully support re-enlightenment notifications and doesn't +emulate TSC accesses after migration so 'tsc-frequency=' CPU option also has to +be specified to make migration succeed. The destination host has to either have +the same TSC frequency or support TSC scaling CPU feature. + Recommended: hv-frequencies 3.16. hv-evmcs diff --git a/target/i386/kvm/hyperv-proto.h b/target/i386/kvm/hyperv-proto.h index 056a305be3..e30d64b4ad 100644 --- a/target/i386/kvm/hyperv-proto.h +++ b/target/i386/kvm/hyperv-proto.h @@ -139,6 +139,7 @@ * Reenlightenment notification MSRs */ #define HV_X64_MSR_REENLIGHTENMENT_CONTROL 0x40000106 +#define HV_REENLIGHTENMENT_ENABLE_BIT (1u << 16) #define HV_X64_MSR_TSC_EMULATION_CONTROL 0x40000107 #define HV_X64_MSR_TSC_EMULATION_STATUS 0x40000108 diff --git a/target/i386/machine.c b/target/i386/machine.c index 7259fe6868..137604ddb8 100644 --- a/target/i386/machine.c +++ b/target/i386/machine.c @@ -883,11 +883,31 @@ static bool hyperv_reenlightenment_enable_needed(void *opaque) env->msr_hv_tsc_emulation_status != 0; } +static int hyperv_reenlightenment_post_load(void *opaque, int version_id) +{ + X86CPU *cpu = opaque; + CPUX86State *env = &cpu->env; + + /* + * KVM doesn't fully support re-enlightenment notifications so we need to + * make sure TSC frequency doesn't change upon migration. + */ + if ((env->msr_hv_reenlightenment_control & HV_REENLIGHTENMENT_ENABLE_BIT) && + !env->user_tsc_khz) { + error_report("Guest enabled re-enlightenment notifications, " + "'tsc-frequency=' has to be specified"); + return -EINVAL; + } + + return 0; +} + static const VMStateDescription vmstate_msr_hyperv_reenlightenment = { .name = "cpu/msr_hyperv_reenlightenment", .version_id = 1, .minimum_version_id = 1, .needed = hyperv_reenlightenment_enable_needed, + .post_load = hyperv_reenlightenment_post_load, .fields = (VMStateField[]) { VMSTATE_UINT64(env.msr_hv_reenlightenment_control, X86CPU), VMSTATE_UINT64(env.msr_hv_tsc_emulation_control, X86CPU), |