qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2] i386: Make 'hv-reenlightenment' require explicit 'tsc-frequency' setting
@ 2021-03-31 11:39 Vitaly Kuznetsov
  2021-04-14 13:26 ` Eduardo Habkost
  0 siblings, 1 reply; 5+ messages in thread
From: Vitaly Kuznetsov @ 2021-03-31 11:39 UTC (permalink / raw)
  To: qemu-devel, Paolo Bonzini
  Cc: Eduardo Habkost, David Edmondson, Michael S. Tsirkin,
	Richard Henderson, Dr . David Alan Gilbert

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>
---
Changes since v1:
- Typos in commit message/comment fixed [David Edmondson]
- Add Acked-by tag [Dr. David Alan Gilbert]
---
 docs/hyperv.txt   |  1 +
 hw/i386/pc.c      |  1 +
 target/i386/cpu.c | 23 +++++++++++++++++++++--
 target/i386/cpu.h |  1 +
 4 files changed, 24 insertions(+), 2 deletions(-)

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;
-- 
2.30.2



^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH v2] i386: Make 'hv-reenlightenment' require explicit 'tsc-frequency' setting
  2021-03-31 11:39 [PATCH v2] i386: Make 'hv-reenlightenment' require explicit 'tsc-frequency' setting Vitaly Kuznetsov
@ 2021-04-14 13:26 ` Eduardo Habkost
  2021-04-14 13:51   ` Vitaly Kuznetsov
  0 siblings, 1 reply; 5+ messages in thread
From: Eduardo Habkost @ 2021-04-14 13:26 UTC (permalink / raw)
  To: Vitaly Kuznetsov
  Cc: Michael S. Tsirkin, David Edmondson, Richard Henderson,
	qemu-devel, Dr . David Alan Gilbert, Paolo Bonzini

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



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v2] i386: Make 'hv-reenlightenment' require explicit 'tsc-frequency' setting
  2021-04-14 13:26 ` Eduardo Habkost
@ 2021-04-14 13:51   ` Vitaly Kuznetsov
  2021-04-14 14:39     ` Eduardo Habkost
  0 siblings, 1 reply; 5+ messages in thread
From: Vitaly Kuznetsov @ 2021-04-14 13:51 UTC (permalink / raw)
  To: Eduardo Habkost
  Cc: Michael S. Tsirkin, David Edmondson, Richard Henderson,
	qemu-devel, Dr . David Alan Gilbert, Paolo Bonzini

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.

-- 
Vitaly



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v2] i386: Make 'hv-reenlightenment' require explicit 'tsc-frequency' setting
  2021-04-14 13:51   ` Vitaly Kuznetsov
@ 2021-04-14 14:39     ` Eduardo Habkost
  2021-04-15  9:31       ` Vitaly Kuznetsov
  0 siblings, 1 reply; 5+ messages in thread
From: Eduardo Habkost @ 2021-04-14 14:39 UTC (permalink / raw)
  To: Vitaly Kuznetsov
  Cc: Michael S. Tsirkin, David Edmondson, Richard Henderson,
	qemu-devel, Dr . David Alan Gilbert, Paolo Bonzini

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



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v2] i386: Make 'hv-reenlightenment' require explicit 'tsc-frequency' setting
  2021-04-14 14:39     ` Eduardo Habkost
@ 2021-04-15  9:31       ` Vitaly Kuznetsov
  0 siblings, 0 replies; 5+ messages in thread
From: Vitaly Kuznetsov @ 2021-04-15  9:31 UTC (permalink / raw)
  To: Eduardo Habkost
  Cc: Michael S. Tsirkin, David Edmondson, Richard Henderson,
	qemu-devel, Dr . David Alan Gilbert, Paolo Bonzini

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!

-- 
Vitaly



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-04-15  9:32 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-31 11:39 [PATCH v2] i386: Make 'hv-reenlightenment' require explicit 'tsc-frequency' setting Vitaly Kuznetsov
2021-04-14 13:26 ` Eduardo Habkost
2021-04-14 13:51   ` Vitaly Kuznetsov
2021-04-14 14:39     ` Eduardo Habkost
2021-04-15  9:31       ` Vitaly Kuznetsov

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).