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>


diff -r b928797213ac xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Fri Dec 11 09:17:09 2009 +0000
+++ b/xen/arch/x86/hvm/hvm.c	Fri Dec 11 11:05:44 2009 -0500
@@ -2331,14 +2331,32 @@
 
 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