[Qemu-devel] QEMU/MIPS & dyntick kernel

[Aurelien Jarno]

Hi,

As announced by Ralf Baechle, dyntick is now available on MIPS. I gave a
try on QEMU/MIPS, and unfortunately it doesn't work correctly.

In some cases the kernel schedules an event very near in the future, 
which means the timer is scheduled a few cycles only from its current
value. Unfortunately under QEMU, the timer runs too fast compared to the
speed at which instructions are execution. This causes a lockup of the
kernel. This can be triggered by running hwclock --hctosys in the guest
(which is run at boot time by most distributions). Until now, I haven't 
found any other way to trigger the bug.

The problematic code in the kernel from arch/mips/kernel/time.c is the
following:

        cnt = read_c0_count();
        cnt += delta;
        write_c0_compare(cnt);
        res = ((long)(read_c0_count() - cnt ) > 0) ? -ETIME : 0;

Note that there is a minimum value for delta (currently set to 48) to 
avoid lockup.

In QEMU, the emulated kernel runs at 100 MHz, ie very fast, which means
that more than 48 timer cycles happen between the two calls of
read_c0_count(). The code returns -ETIME, and the routine is called
again with 48 and so on.

I have tried to reduce the speed of the timer, the problem disappears
when running at 1MHz (on my machine).

Here are a few proposed ways to fix the problem (they are not exclusive):

1) Improve the emulation speed for timer instructions. This is what I
did with the attached patch. I see no obvious reason of stopping the
translation after a write to CP0_Compare, so I removed that part. I also
reduced the code that emulates timer accesses.

That helps but that is clearly not enough. With this patch the maximum
timer speed is 5MHz.

2) Increase the minimum value for delta. For a 100MHz timer 48 cycles 
means 480ns. On the other side a kernel running at 250Hz (default on 
MIPS) is scheduling tasks with a 4ms resolution.

Increasing it to about 10 microseconds should have no impact on the
scheduling, even on real hardware.

3) Reduce the timer speed. As the timer is supposed to run at half the
speed of the CPU, that would mean the kernel would see a 2 to 10MHz 
CPU.

4) Add a hack to QEMU to make the timer slower within a translation
block (like increasing it by 1 at each access), without changing the
overall speed. This might break other parts or other OSeS.


Any thoughts or other ideas?

Bye,
Aurelien

[1] http://www.linux-mips.org/archives/linux-mips/2007-09/msg00372.html

-- 
  .''`.  Aurelien Jarno             | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   address@hidden         | address@hidden
   `-    people.debian.org/~aurel32 | www.aurel32.net

mips-qemu-timer.diff
Description: Text Data