ia64/xen-unstable

changeset 10602:3dfc2583a4f1

[XEN] Fix the timeout workaround so it doesn't capture negative
diffs relative to current time.
Signed-off-by: Keir Fraser <keir@xensource.com>
author kfraser@dhcp93.uk.xensource.com
date Thu Jun 29 16:59:47 2006 +0100 (2006-06-29)
parents 8242c0c24db7
children de263308be3b
files xen/common/schedule.c
line diff
     1.1 --- a/xen/common/schedule.c	Thu Jun 29 15:02:38 2006 +0100
     1.2 +++ b/xen/common/schedule.c	Thu Jun 29 16:59:47 2006 +0100
     1.3 @@ -389,30 +389,30 @@ long do_sched_op(int cmd, XEN_GUEST_HAND
     1.4  long do_set_timer_op(s_time_t timeout)
     1.5  {
     1.6      struct vcpu *v = current;
     1.7 +    s_time_t offset = timeout - NOW();
     1.8  
     1.9      if ( timeout == 0 )
    1.10      {
    1.11          stop_timer(&v->timer);
    1.12      }
    1.13 +    else if ( unlikely(timeout < 0) || /* overflow into 64th bit? */
    1.14 +              unlikely((offset > 0) && ((uint32_t)(offset >> 50) != 0)) )
    1.15 +    {
    1.16 +        /*
    1.17 +         * Linux workaround: occasionally we will see timeouts a long way in 
    1.18 +         * the future due to wrapping in Linux's jiffy time handling. We check 
    1.19 +         * for timeouts wrapped negative, and for positive timeouts more than 
    1.20 +         * about 13 days in the future (2^50ns). The correct fix is to trigger 
    1.21 +         * an interrupt immediately (since Linux in fact has pending work to 
    1.22 +         * do in this situation).
    1.23 +         */
    1.24 +        DPRINTK("Warning: huge timeout set by domain %d (vcpu %d):"
    1.25 +                " %"PRIx64"\n",
    1.26 +                v->domain->domain_id, v->vcpu_id, (uint64_t)timeout);
    1.27 +        send_timer_event(v);
    1.28 +    }
    1.29      else
    1.30      {
    1.31 -        if ( unlikely(timeout < 0) ||
    1.32 -             unlikely((uint32_t)((timeout - NOW()) >> 50) != 0) )
    1.33 -        {
    1.34 -            /*
    1.35 -             * Linux workaround: occasionally we will see timeouts a long way
    1.36 -             * in the future due to wrapping in Linux's jiffy time handling.
    1.37 -             * We check for tiemouts wrapped negative, and for positive
    1.38 -             * timeouts more than about 13 days in the future (2^50ns).
    1.39 -             * The correct fix is to trigger an interrupt in a short while
    1.40 -             * (since Linux in fact has pending work to do in this situation).
    1.41 -             */
    1.42 -            DPRINTK("Warning: huge timeout set by domain %d (vcpu %d):"
    1.43 -                    " %"PRIx64"\n",
    1.44 -                    v->domain->domain_id, v->vcpu_id, (uint64_t)timeout);
    1.45 -            timeout = NOW() + MILLISECS(10);
    1.46 -        }
    1.47 -
    1.48          set_timer(&v->timer, timeout);
    1.49      }
    1.50