Re: [Qemu-devel] [PATCH v6 2/4] cadence_ttc: initial version of device model

[Paul Brook <paul@codesourcery.com>]

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