[Xen-changelog] [xen master] x86/HVM: fix initialization of wallclock time for PVHVM on migration

[patchbot@xxxxxxx]

commit f8e8fd56bd7d5675e8331b4ec74bae76c9dbf24e
Author:     Roger Pau Monné <roger.pau@xxxxxxxxxx>
AuthorDate: Wed Jun 12 10:05:39 2013 +0200
Commit:     Jan Beulich <jbeulich@xxxxxxxx>
CommitDate: Wed Jun 12 10:05:39 2013 +0200

    x86/HVM: fix initialization of wallclock time for PVHVM on migration
    
    Call update_domain_wallclock_time on hvm_latch_shinfo_size even if
    the bitness of the guest has already been set, this fixes the problem
    with the wallclock not being set for PVHVM guests on resume from
    migration.
    
    Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    
    Clean up the resulting code and retain the (slightly adjusted) original
    comment.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
---
 xen/arch/x86/hvm/hvm.c |   33 ++++++++++++++-------------------
 1 files changed, 14 insertions(+), 19 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index ce44bff..27484e9 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3386,31 +3386,26 @@ 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 ) {
-        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);
-        }
+    if ( current->domain == d )
+    {
+        d->arch.has_32bit_shinfo = (hvm_guest_x86_mode(current) != 8);
+        /*
+         * Make sure that the timebase in the shared info structure is correct.
+         *
+         * If the bit-ness changed 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);
     }
 }
 
--
generated by git-patchbot for /home/xen/git/xen.git#master

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