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@citrix.com>
Signed-off-by: Keith Coleman <keith@scaltro.com>

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index d2e8a7162ec4832d0e57dac3b4e28e59e97f90d1..4db67b8357b0243f4dd2a1a43c7577516e8143e3 100644 (file)
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2331,14 +2331,32 @@ int hvm_do_hypercall(struct cpu_user_regs *regs)
 
 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