| Message ID | 20210331113948.333461-1-vkuznets@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] i386: Make 'hv-reenlightenment' require explicit 'tsc-frequency' setting | expand |
My apologies, this was lost under the noise in my mail inbox. (I promise I'm trying to improve) On Wed, Mar 31, 2021 at 01:39:48PM +0200, Vitaly Kuznetsov wrote: > 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, > require 'tsc-frequency=' on the command line when 'hv-reenlightenment' was > enabled. Make the change affect 6.0+ machine types only to preserve > previously-valid configurations. > > Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> > Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Even if the 6.0 release gets delayed, I wouldn't be comfortable including this in a -rc4. What if the user does not plan to live migrate the machine at all? Why is this case different from the ~25 migrate_add_blocker() calls in QEMU, where we block migration but still let the VM run?
Eduardo Habkost <ehabkost@redhat.com> writes: > My apologies, this was lost under the noise in my mail inbox. > (I promise I'm trying to improve) > > On Wed, Mar 31, 2021 at 01:39:48PM +0200, Vitaly Kuznetsov wrote: >> 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, >> require 'tsc-frequency=' on the command line when 'hv-reenlightenment' was >> enabled. Make the change affect 6.0+ machine types only to preserve >> previously-valid configurations. >> >> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> >> Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com> > > Even if the 6.0 release gets delayed, I wouldn't be comfortable > including this in a -rc4. > > What if the user does not plan to live migrate the machine at > all? Why is this case different from the ~25 > migrate_add_blocker() calls in QEMU, where we block migration but > still let the VM run? The question is when do we want to let the user know about the problem. By refusing to start with 'hv-reenlightenment' and without 'tsc-frequency' we make it sure he knows early. We can, indeed, replace this with migrate_add_blocker() call but the fact that the VM is not migratable may come as a (late) surprise (we can certainly print a warning but these may be hidden by upper layers). Also, v1 of this patch was implementing a slightly different approach failing the migration late if we can't set tsc frequency on the destination host. Explicit 'tsc-frequency=' was not required. Personally, I'm comfortable with any approach, please advise.
On Wed, Apr 14, 2021 at 03:51:37PM +0200, Vitaly Kuznetsov wrote: > Eduardo Habkost <ehabkost@redhat.com> writes: > > > My apologies, this was lost under the noise in my mail inbox. > > (I promise I'm trying to improve) > > > > On Wed, Mar 31, 2021 at 01:39:48PM +0200, Vitaly Kuznetsov wrote: > >> 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, > >> require 'tsc-frequency=' on the command line when 'hv-reenlightenment' was > >> enabled. Make the change affect 6.0+ machine types only to preserve > >> previously-valid configurations. > >> > >> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> > >> Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com> > > > > Even if the 6.0 release gets delayed, I wouldn't be comfortable > > including this in a -rc4. > > > > What if the user does not plan to live migrate the machine at > > all? Why is this case different from the ~25 > > migrate_add_blocker() calls in QEMU, where we block migration but > > still let the VM run? > > The question is when do we want to let the user know about the > problem. By refusing to start with 'hv-reenlightenment' and without > 'tsc-frequency' we make it sure he knows early. > > We can, indeed, replace this with migrate_add_blocker() call but the > fact that the VM is not migratable may come as a (late) surprise (we > can certainly print a warning but these may be hidden by upper layers). > > Also, v1 of this patch was implementing a slightly different approach > failing the migration late if we can't set tsc frequency on the > destination host. Explicit 'tsc-frequency=' was not required. > > Personally, I'm comfortable with any approach, please advise. I agree with what you are trying to do, I just wonder why we wouldn't do exactly the same for all other migrate_add_blocker() calls too (whatever the solution we choose here). I'd suggest the following: - For people who use "-only-migratable", using migrate_add_blocker() here already solves the problem. - For people who don't use "-only-migratable", we could change migrate_add_blocker() to print a warning by default (only on machine types where live migration is supported). - For people who don't need live migration and don't want to see those warnings, we can introduce a "-no-migration" option.
Eduardo Habkost <ehabkost@redhat.com> writes: > On Wed, Apr 14, 2021 at 03:51:37PM +0200, Vitaly Kuznetsov wrote: >> Eduardo Habkost <ehabkost@redhat.com> writes: >> >> > My apologies, this was lost under the noise in my mail inbox. >> > (I promise I'm trying to improve) >> > >> > On Wed, Mar 31, 2021 at 01:39:48PM +0200, Vitaly Kuznetsov wrote: >> >> 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, >> >> require 'tsc-frequency=' on the command line when 'hv-reenlightenment' was >> >> enabled. Make the change affect 6.0+ machine types only to preserve >> >> previously-valid configurations. >> >> >> >> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> >> >> Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com> >> > >> > Even if the 6.0 release gets delayed, I wouldn't be comfortable >> > including this in a -rc4. >> > >> > What if the user does not plan to live migrate the machine at >> > all? Why is this case different from the ~25 >> > migrate_add_blocker() calls in QEMU, where we block migration but >> > still let the VM run? >> >> The question is when do we want to let the user know about the >> problem. By refusing to start with 'hv-reenlightenment' and without >> 'tsc-frequency' we make it sure he knows early. >> >> We can, indeed, replace this with migrate_add_blocker() call but the >> fact that the VM is not migratable may come as a (late) surprise (we >> can certainly print a warning but these may be hidden by upper layers). >> >> Also, v1 of this patch was implementing a slightly different approach >> failing the migration late if we can't set tsc frequency on the >> destination host. Explicit 'tsc-frequency=' was not required. >> >> Personally, I'm comfortable with any approach, please advise. > > I agree with what you are trying to do, I just wonder why we > wouldn't do exactly the same for all other migrate_add_blocker() > calls too (whatever the solution we choose here). > > I'd suggest the following: > > - For people who use "-only-migratable", using > migrate_add_blocker() here already solves the problem. > > - For people who don't use "-only-migratable", we could change > migrate_add_blocker() to print a warning by default (only on > machine types where live migration is supported). > > - For people who don't need live migration and don't want to see > those warnings, we can introduce a "-no-migration" option. All make sense to me, let me try to draft v3 based on your proposal. Thanks!
diff --git a/docs/hyperv.txt b/docs/hyperv.txt index e53c581f4586..5b02d341ab25 100644 --- a/docs/hyperv.txt +++ b/docs/hyperv.txt @@ -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 Recommended: hv-frequencies 3.16. hv-evmcs diff --git a/hw/i386/pc.c b/hw/i386/pc.c index 8a84b25a031e..47b79e949ad7 100644 --- a/hw/i386/pc.c +++ b/hw/i386/pc.c @@ -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); diff --git a/target/i386/cpu.c b/target/i386/cpu.c index 6b3e9467f177..dbcd2ffbbbe5 100644 --- a/target/i386/cpu.c +++ b/target/i386/cpu.c @@ -6647,10 +6647,23 @@ static void x86_cpu_filter_features(X86CPU *cpu, bool verbose) } } -static void x86_cpu_hyperv_realize(X86CPU *cpu) +static void x86_cpu_hyperv_realize(X86CPU *cpu, Error **errp) { + CPUX86State *env = &cpu->env; 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(errp, "'hv-reenlightenment' requires 'tsc-frequency' to be set"); + return; + } + /* Hyper-V vendor id */ if (!cpu->hyperv_vendor) { memcpy(cpu->hyperv_vendor_id, "Microsoft Hv", 12); @@ -6846,7 +6859,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 +7391,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() diff --git a/target/i386/cpu.h b/target/i386/cpu.h index 570f916878f9..0196a300f018 100644 --- a/target/i386/cpu.h +++ b/target/i386/cpu.h @@ -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;