On Tue, Feb 28, 2012 at 10:07 PM, Paul Brook <p...@codesourcery.com> wrote: >> > Thinking about that, I realised why I don't like the following line: >> >> + s->reg_value = (uint32_t)((x + interval) % interval); >> > >> > This assumes x > -interval, which is not always true. >> >> This would mean you have wrapped twice or more in one time step, which >> I am assuming is a fatal error condition, as It means your software >> has missed interrupts and all sort of race conditions would occur. I >> would personally prefer to assert !(x < -interval) and have qemu >> hw_error or something, as in these cases QEMU can just not handle your >> super quick timer wrap around. > > No, not fatal at all. On a heavily loaded host it's normal for qemu[1] to > stall for tens of miliseconds at a time. In extreme cases several seconds at > a time, though we've fixed most of those. This is greater than the interval > of many guest periodic events. A linux guest with HZ=1000 (even HZ=100) will > routinely loose timer ticks. By my reading your timers have a configurable > limit, so the obvious configuration is a limit of 25000 (2.5MHz / 100), and > trigger the jiffy tick off the timer wrap/reload. >
Yeh i discovered that in testing :) my hw_error did trigger under linux. Fixed that % issue you raised (in v8) such this it will not % a -ve number when the timer multi-wraps. > If your guest OS assumes their ISR will complete before timer triggers again > then it will break. That's their problem. Any guest that relies on > consistent realtime performance/behavior is going to malfunction when run > inside qemu. This is only one of several ways that qemu behavior can differ > from that of real hardware. > > You can workaround some of these issues with -icount, though that has its own > set of problems. One of which is that is doesn't support KVM or SMP[2]. > guests. > > Paul > > [1] The same applies for KVM. > [2] SMP may be fixable. KVM probably not. Peter