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

[Peter Crosthwaite]

On Tue, Feb 28, 2012 at 10:07 PM, Paul Brook <address@hidden> 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