[Qemu-discuss] Time warp to far ahead.

[alarson]

When running our RTOS under QEMU (initially 2.6.0, but I verified the
same behavior on 2.8 rc4), we've seen situations where virtual time is
advanced past when virtual timers are set to expire.  When the virtual
timer fires, it appears with a very large latency (i.e., "in the
past"), in our case 10's of milliseconds.  The problem manifests on
both ARM and PPC guests, which are the only ones I tested.  The timers
in question are the PPC timestamp and decrementer, and on ARM the GIC
timer.

I tracked the problem down to icount_warp_rt(), which is advancing
time to QEMU_CLOCK_VIRTUAL_RT which is beyond QEMU_CLOCK_VIRTUAL.  If
I cap the time warp to the min of the VIRTUAL and VIRTUAL_RT, then
time is as expected.  The following is a patch against 2.6.0, but the
code in question is unchanged in 2.8 rc4:
Index: cpus.c
===================================================================
--- cpus.c
+++ cpus.c
@@ -353,6 +353,7 @@
         return;
     }
 
+    int64_t clock_vt = qemu_clock_deadline_ns_all(QEMU_CLOCK_VIRTUAL);
     seqlock_write_lock(&timers_state.vm_clock_seqlock);
     if (runstate_is_running()) {
         int64_t clock = REPLAY_CLOCK(REPLAY_CLOCK_VIRTUAL_RT,
@@ -369,6 +370,7 @@
             int64_t delta = clock - cur_icount;
             warp_delta = MIN(warp_delta, delta);
         }
+        warp_delta = MIN(warp_delta, clock_vt);
         timers_state.qemu_icount_bias += warp_delta;
     }
     vm_clock_warp_start = -1;

The above is probably not the proper patch because the acquisition of
the VIRTUAL time is gotten outside of the lock, but I wanted to get
some general concurrence that there is a problem and that this is the
proper type of solution before delving further into the "real"
solution.

Comments/guidance solicited.

Aaron.