@@ -165,6 +165,7 @@ 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.
+Requires: tsc-frequency (for migration)
Recommended: hv-frequencies
3.16. hv-evmcs
@@ -98,6 +98,7 @@
GlobalProperty pc_compat_5_2[] = {
{ "ICH9-LPC", "x-smi-cpu-hotunplug", "off" },
+ { TYPE_X86_CPU, "x-hv-reenlightenment-requires-tscfreq", "off"},
};
const size_t pc_compat_5_2_len = G_N_ELEMENTS(pc_compat_5_2);
@@ -56,6 +56,7 @@
#include "sysemu/tcg.h"
#include "hw/qdev-properties.h"
#include "hw/i386/topology.h"
+#include "migration/blocker.h"
#ifndef CONFIG_USER_ONLY
#include "exec/address-spaces.h"
#include "hw/i386/apic_internal.h"
@@ -6647,10 +6648,33 @@ static void x86_cpu_filter_features(X86CPU *cpu, bool verbose)
}
}
-static void x86_cpu_hyperv_realize(X86CPU *cpu)
+static Error *hv_reenlightenment_mig_blocker;
+
+static void x86_cpu_hyperv_realize(X86CPU *cpu, Error **errp)
{
+ CPUX86State *env = &cpu->env;
+ Error *local_err = NULL;
size_t len;
+ /*
+ * Reenlightenment requires explicit 'tsc-frequency' setting for successful
+ * migration (see hyperv_reenlightenment_post_load()). As 'hv-passthrough'
+ * mode is not migratable, we can loosen the restriction.
+ */
+ if (hyperv_feat_enabled(cpu, HYPERV_FEAT_REENLIGHTENMENT) &&
+ !cpu->hyperv_passthrough && !env->user_tsc_khz &&
+ cpu->hyperv_reenlightenment_requires_tscfreq) {
+
+ error_setg(&hv_reenlightenment_mig_blocker,
+ "'hv-reenlightenment' requires 'tsc-frequency' to be set");
+
+ migrate_add_blocker(hv_reenlightenment_mig_blocker, &local_err);
+ if (local_err != NULL) {
+ error_propagate(errp, local_err);
+ return;
+ }
+ }
+
/* Hyper-V vendor id */
if (!cpu->hyperv_vendor) {
memcpy(cpu->hyperv_vendor_id, "Microsoft Hv", 12);
@@ -6846,7 +6870,11 @@ static void x86_cpu_realizefn(DeviceState *dev, Error **errp)
}
/* Process Hyper-V enlightenments */
- x86_cpu_hyperv_realize(cpu);
+ x86_cpu_hyperv_realize(cpu, &local_err);
+ if (local_err != NULL) {
+ error_propagate(errp, local_err);
+ return;
+ }
cpu_exec_realizefn(cs, &local_err);
if (local_err != NULL) {
@@ -7374,6 +7402,8 @@ static Property x86_cpu_properties[] = {
DEFINE_PROP_INT32("x-hv-max-vps", X86CPU, hv_max_vps, -1),
DEFINE_PROP_BOOL("x-hv-synic-kvm-only", X86CPU, hyperv_synic_kvm_only,
false),
+ DEFINE_PROP_BOOL("x-hv-reenlightenment-requires-tscfreq", X86CPU,
+ hyperv_reenlightenment_requires_tscfreq, true),
DEFINE_PROP_BOOL("x-intel-pt-auto-level", X86CPU, intel_pt_auto_level,
true),
DEFINE_PROP_END_OF_LIST()
@@ -1677,6 +1677,7 @@ struct X86CPU {
uint32_t hyperv_spinlock_attempts;
char *hyperv_vendor;
bool hyperv_synic_kvm_only;
+ bool hyperv_reenlightenment_requires_tscfreq;
uint64_t hyperv_features;
bool hyperv_passthrough;
OnOffAuto hyperv_no_nonarch_cs;
Commit 561dbb41b1d7 "i386: Make migration fail when Hyper-V reenlightenment was enabled but 'user_tsc_khz' is unset" forbade migrations with when guest has opted for reenlightenment notifications but 'tsc-frequency' wasn't set explicitly on the command line. This works but the migration fails late and this may come as an unpleasant surprise. To make things more explicit, add a migration blocker when 'hv-reenlightenment' was enabled but 'tsc-frequency' is unset. Make the change affect 6.0+ machine types only to preserve previously-valid configurations. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> --- Changes since v2: - Use migrate_add_blocker() [Eduardo] Note: In case this patch gets queued for 6.1 an adjustment is needed: { TYPE_X86_CPU, "x-hv-reenlightenment-requires-tscfreq", "off"} needs to go to not-yet-existing 'pc_compat_6_0'. --- docs/hyperv.txt | 1 + hw/i386/pc.c | 1 + target/i386/cpu.c | 34 ++++++++++++++++++++++++++++++++-- target/i386/cpu.h | 1 + 4 files changed, 35 insertions(+), 2 deletions(-)