[Xen-changelog] [xen-unstable] [XEN] Fix the timeout workaround so it doesn't capture negative

[Xen patchbot-unstable <patchbot-unstable@xxxxxxxxxxxxxxxxxxx>]

# HG changeset patch
# User kfraser@xxxxxxxxxxxxxxxxxxxxxxx
# Node ID 3dfc2583a4f161a81ee0dcbba8e23e328577f687
# Parent  8242c0c24db75c7de381b69637b7b1be3f4780f1
[XEN] Fix the timeout workaround so it doesn't capture negative
diffs relative to current time.
Signed-off-by: Keir Fraser <keir@xxxxxxxxxxxxx>
---
 xen/common/schedule.c |   34 +++++++++++++++++-----------------
 1 files changed, 17 insertions(+), 17 deletions(-)

diff -r 8242c0c24db7 -r 3dfc2583a4f1 xen/common/schedule.c
--- a/xen/common/schedule.c     Thu Jun 29 15:02:38 2006 +0100
+++ b/xen/common/schedule.c     Thu Jun 29 16:59:47 2006 +0100
@@ -389,30 +389,30 @@ long do_set_timer_op(s_time_t timeout)
 long do_set_timer_op(s_time_t timeout)
 {
     struct vcpu *v = current;
+    s_time_t offset = timeout - NOW();
 
     if ( timeout == 0 )
     {
         stop_timer(&v->timer);
     }
+    else if ( unlikely(timeout < 0) || /* overflow into 64th bit? */
+              unlikely((offset > 0) && ((uint32_t)(offset >> 50) != 0)) )
+    {
+        /*
+         * Linux workaround: occasionally we will see timeouts a long way in 
+         * the future due to wrapping in Linux's jiffy time handling. We check 
+         * for timeouts wrapped negative, and for positive timeouts more than 
+         * about 13 days in the future (2^50ns). The correct fix is to trigger 
+         * an interrupt immediately (since Linux in fact has pending work to 
+         * do in this situation).
+         */
+        DPRINTK("Warning: huge timeout set by domain %d (vcpu %d):"
+                " %"PRIx64"\n",
+                v->domain->domain_id, v->vcpu_id, (uint64_t)timeout);
+        send_timer_event(v);
+    }
     else
     {
-        if ( unlikely(timeout < 0) ||
-             unlikely((uint32_t)((timeout - NOW()) >> 50) != 0) )
-        {
-            /*
-             * Linux workaround: occasionally we will see timeouts a long way
-             * in the future due to wrapping in Linux's jiffy time handling.
-             * We check for tiemouts wrapped negative, and for positive
-             * timeouts more than about 13 days in the future (2^50ns).
-             * The correct fix is to trigger an interrupt in a short while
-             * (since Linux in fact has pending work to do in this situation).
-             */
-            DPRINTK("Warning: huge timeout set by domain %d (vcpu %d):"
-                    " %"PRIx64"\n",
-                    v->domain->domain_id, v->vcpu_id, (uint64_t)timeout);
-            timeout = NOW() + MILLISECS(10);
-        }
-
         set_timer(&v->timer, timeout);
     }
 

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