Re: [Qemu-devel] [PATCH] sparc64: reimplement tick timers v3

[Igor Kovalenko <igor.v.kovalenko@gmail.com>]

On Fri, Jan 22, 2010 at 11:32 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
> On Tue, Jan 19, 2010 at 10:25 PM, Igor V. Kovalenko
> <igor.v.kovalenko@gmail.com> wrote:
>> From: Igor V. Kovalenko <igor.v.kovalenko@gmail.com>
>>
>> sparc64 timer has tick counter which can be set and read,
>> and tick compare value used as deadline to fire timer interrupt.
>> The timer is not used as periodic timer, instead deadline
>> is set each time new timer interrupt is needed.
>>
>> v2 -> v3:
>> - added missing timer debug output macro
>> - CPUTimer struct and typedef moved to cpu.h
>> - change CPU_SAVE_VERSION to 6, older save formats not supported
>>
>> v1 -> v2:
>> - new conversion helpers cpu_to_timer_ticks and timer_to_cpu_ticks
>> - save offset from clock source to implement cpu_tick_set_count
>> - renamed struct sun4u_timer to CPUTimer
>> - load and save cpu timers
>>
>> v0 -> v1:
>> - coding style
>
> My debugging of Linux panic has not been very fruitful. Once I got the
> panic triggered while single stepping calibrate_delay() with GDB and
> keeping enter key pressed. Then I missed the fault though.
>
> One possible problem is that 4dc28134f3d7db0033c6b3c5bc4be9a91adb3e2b
> added interrupt checks to the helpers which means that they can cause
> faults, but translation of the instructions was not changed to take
> this into account. But when I added calls to save_state() in
> translate.c, it didn't change anything.

The issue is with PUT_CWP64 - linux kernel does read cwp which
happens to be zero, decrements it and writes the result to cwp.
Expected value is max window id but we store zero cwp,
and return path from trap handler does restore wrong window.

I'll post the fix now, and then try to clean up the rest of timer patch.

-- 
Kind regards,
Igor V. Kovalenko