[Xen-changelog] [xen-unstable] Fix clock for XCP Windows PV drivers on restore

[Xen patchbot-unstable <patchbot-unstable@xxxxxxxxxxxxxxxxxxx>]

# HG changeset patch
# User Keir Fraser <keir.fraser@xxxxxxxxxx>
# Date 1260777335 0
# Node ID db8a985693f7ce37d3daee0023266ce8758ddae7
# Parent  2d9c58c29a94033ad7e51c2ec23fc66a92a9e391
Fix clock for XCP Windows PV drivers on restore

This fixes a timekeeping issue for 32 bit guests running XCP Windows
paravirtual drivers on a 64 bit hypervisor where their clock was set
to the 1970s after live migration or restore. Thanks to Paul Durrant
for helping track this down.

>From the original XCP patch:

Arrange that the wallclock time fields in the shared_info structure
are set correctly in 32 bit HVM guests on a 64 bit hypervisor.  HVM
guests on a 64 bit hypervisor always start with a 64 bit shared info,
and then change to a 32 bit one if they're using 32 bit drivers.  The
32-bit and 64-bit shared info structures put their wallclock times in
slightly different places, and so the wallclock time needs to be
regenerated when you do the conversion.

It can be argued that we should convert the other fields of shared
info at the same time (e.g. if an event channel is pending beforehand,
it should be pending afterwards), but that's much harder to arrange,
because the 32 bit structure can't represent all the states which the
64 bit one can.  Just setting the time seems to be sufficient for
our purposes.

Signed-off-by: Steven Smith <steven.smith@xxxxxxxxxx>
Signed-off-by: Keith Coleman <keith@xxxxxxxxxxx>
---
 xen/arch/x86/hvm/hvm.c |   22 ++++++++++++++++++++--
 1 files changed, 20 insertions(+), 2 deletions(-)

diff -r 2d9c58c29a94 -r db8a985693f7 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c    Mon Dec 14 07:54:53 2009 +0000
+++ b/xen/arch/x86/hvm/hvm.c    Mon Dec 14 07:55:35 2009 +0000
@@ -2331,14 +2331,32 @@ int hvm_do_hypercall(struct cpu_user_reg
 
 static void hvm_latch_shinfo_size(struct domain *d)
 {
+    bool_t new_has_32bit;
+
     /*
      * Called from operations which are among the very first executed by
      * PV drivers on initialisation or after save/restore. These are sensible
      * points at which to sample the execution mode of the guest and latch
      * 32- or 64-bit format for shared state.
      */
-    if ( current->domain == d )
-        d->arch.has_32bit_shinfo = (hvm_guest_x86_mode(current) != 8);
+    if ( current->domain == d ) {
+        new_has_32bit = (hvm_guest_x86_mode(current) != 8);
+        if (new_has_32bit != d->arch.has_32bit_shinfo) {
+            d->arch.has_32bit_shinfo = new_has_32bit;
+            /*
+             * Make sure that the timebase in the shared info
+             * structure is correct for its new bit-ness.  We should
+             * arguably try to convert the other fields as well, but
+             * that's much more problematic (e.g. what do you do if
+             * you're going from 64 bit to 32 bit and there's an event
+             * channel pending which doesn't exist in the 32 bit
+             * version?).  Just setting the wallclock time seems to be
+             * sufficient for everything we do, even if it is a bit of
+             * a hack.
+             */
+            update_domain_wallclock_time(d);
+        }
+    }
 }
 
 /* Initialise a hypercall transfer page for a VMX domain using

_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-changelog