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

[Blue Swirl]

On Tue, Jan 26, 2010 at 11:09 PM, Igor Kovalenko
<address@hidden> wrote:
> On Fri, Jan 22, 2010 at 11:32 PM, Blue Swirl <address@hidden> wrote:
>> On Tue, Jan 19, 2010 at 10:25 PM, Igor V. Kovalenko
>> <address@hidden> wrote:
>>> From: Igor V. Kovalenko <address@hidden>
>>>
>>> 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.

Excellent analysis! I await your patch anxiously.