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@citrix.com>

Clean up the resulting code and retain the (slightly adjusted) original
comment.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>

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);
     }
 }