> > 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. 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.