[XEN] Work around timeout bug in old Linux kernels where

timeout would erroneously be set far out in the future.
Signed-off-by: Keir Fraser <keir@xensource.com>

diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index 8d2f44be3581f498f63f2a9958281495629ef5b1..cb801040160645f1540e0cc09f5a0c596bf9aed4 100644 (file)
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -391,9 +391,30 @@ long do_set_timer_op(s_time_t timeout)
     struct vcpu *v = current;
 
     if ( timeout == 0 )
+    {
         stop_timer(&v->timer);
+    }
     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);
+    }
 
     return 0;
 }