Re: [Qemu-devel] timer issue on 1.7.0 and later

[Paolo Bonzini <pbonzini@redhat.com>]

Il 08/02/2014 12:48, Alex Bligh ha scritto:
> Rob,
>
> On 7 Feb 2014, at 18:15, Rob Herring wrote:
>
>> I've bisected a problem with system emulation and SMP kernels using
>> per cpu timers to this commit. I can reproduce this problem on ARM
>> emulation with both ARM generic timers (only in 1.7.0) and ARM MPCore
>> timers. Using a single broadcast timer in the guest kernel works fine.
>> My host is ubuntu 13.10.
>
> I don't know the ARM emulation well, but from the description this looks
> like a problem where timers are firing too often. The timer changes have
> tended to uncover bugs elsewhere in the QEMU, for instance setting timer
> expiry times to something very near zero. So far (touch wood) the timer
> changes themselves have been relatively clean.
>
> What I'd suggest you do is run qemu within gdb, and when you have
> seen the sluggish behaviour, set a breakpoint in timerlist_run_timers
> just before the line saying cb(opaque). If I'm right your breakpoint
> should immediately hit. Step in to the callback and note which it is.
> It should always (or nearly always) be the same timer (note the process
> of debugging will cause other timers to expire).

Alex, could you add a trace event to timerlist_run_timers and mod_timer? 
  For timerlist_run_timer it should include the timer (ts), the callback 
and the opaque value.

This would make it simpler to find if this is the cause, and to debug it 
without introducing as much perturbation.

Paolo

> You then want to find where that timer is set and see if the expiry
> value looks silly. Normally the issue is that timer_mod takes an
> argument (i) which is absolute time, not an interval, and (ii) is
> measured in nanoseconds unless the timer's scale has been
> set otherwise (quite often I've seen it read the current time
> in nanoseconds then add an offset in milliseconds).
>
> If you find which timer it is but can't work out why it's doing it,
> I can take another look.