[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [PATCH RFC] handle tsc_tolerance during migration between identical hosts


  • To: xen-devel@xxxxxxxxxxxxx
  • From: Olaf Hering <olaf@xxxxxxxxx>
  • Date: Tue, 11 Apr 2017 11:39:38 +0200
  • Delivery-date: Tue, 11 Apr 2017 09:40:13 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

Testing has shown that domUs with 'tsc_mode=default' can be migrated
safely between identical hardware, even if the measured clock frequency
differs by a few kHz. A change like shown below would allow to migrate
between "2.nnGHz" hosts without enforcing emulation. If the domU is
migrated to a host with "2.mmGHz" the frequency jump might have bad
effects, and tsc emulation might be good even if it comes with a
perfromance penalty.

The change below adds a new boot option to set a tolerance value.
I think its up to the host admin to decide, therefore a global option
should be enough.

Any opinions, also on the name of the cmdline option?


Olaf


--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -43,6 +43,9 @@
 static char __initdata opt_clocksource[10];
 string_param("clocksource", opt_clocksource);
 
+static unsigned int __read_mostly opt_tsc_tolerance;
+integer_param("tsc_tolerance", opt_tsc_tolerance);
+
 unsigned long __read_mostly cpu_khz;  /* CPU clock frequency in kHz. */
 DEFINE_SPINLOCK(rtc_lock);
 unsigned long pit0_ticks;
@@ -1882,6 +1885,8 @@ void tsc_set_info(struct domain *d,
                   uint32_t tsc_mode, uint64_t elapsed_nsec,
                   uint32_t gtsc_khz, uint32_t incarnation)
 {
+    uint32_t khz_diff, tolerated;
+    printk(XENLOG_WARNING "%s: %u %x %lx %x %x\n", __func__, d->domain_id, 
tsc_mode, (unsigned long)elapsed_nsec, gtsc_khz, incarnation);
     if ( is_idle_domain(d) || is_hardware_domain(d) )
     {
         d->arch.vtsc = 0;
@@ -1924,6 +1929,15 @@ void tsc_set_info(struct domain *d,
         d->arch.vtsc_offset = get_s_time() - elapsed_nsec;
         d->arch.tsc_khz = gtsc_khz ?: cpu_khz;
         set_time_scale(&d->arch.vtsc_to_ns, d->arch.tsc_khz * 1000);
+        khz_diff = 0;
+        if (gtsc_khz)
+            khz_diff = cpu_khz > gtsc_khz ? cpu_khz - gtsc_khz : gtsc_khz - 
cpu_khz;
+        if (opt_tsc_tolerance) {
+            tolerated = khz_diff <= opt_tsc_tolerance;
+        } else {
+            tolerated = d->arch.tsc_khz == cpu_khz;
+        }
+        printk("%s: d%u: dom0 has %lu kHz, domU expects %u kHz, difference of 
%u is %s tolerance of %u. (HVM scaling ratio: %llu)\n", __func__, d->domain_id, 
cpu_khz, gtsc_khz, khz_diff, tolerated ? "within" : "outside", 
opt_tsc_tolerance, has_hvm_container_domain(d) ? 
hvm_get_tsc_scaling_ratio(d->arch.tsc_khz) : 0 );
         /*
          * In default mode use native TSC if the host has safe TSC and:
          *  HVM/PVH: host and guest frequencies are the same (either
@@ -1931,10 +1945,8 @@ void tsc_set_info(struct domain *d,
          *  PV: guest has not migrated yet (and thus arch.tsc_khz == cpu_khz)
          */
         if ( tsc_mode == TSC_MODE_DEFAULT && host_tsc_is_safe() &&
-             (has_hvm_container_domain(d) ?
-              (d->arch.tsc_khz == cpu_khz ||
-               hvm_get_tsc_scaling_ratio(d->arch.tsc_khz)) :
-              incarnation == 0) )
+             (tolerated ||
+             (has_hvm_container_domain(d) && 
hvm_get_tsc_scaling_ratio(d->arch.tsc_khz))) )
         {
     case TSC_MODE_NEVER_EMULATE:
             d->arch.vtsc = 0;

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.