|
From: | Paolo Bonzini |
Subject: | Re: [Qemu-devel] [PATCH 3/3] stop the periodic RTC update timer |
Date: | Mon, 09 Jan 2012 09:19:02 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 |
On 01/06/2012 08:37 AM, Zhang, Yang Z wrote:
VMSTATE_BUFFER(cmos_data, RTCState), VMSTATE_UINT8(cmos_index, RTCState), - VMSTATE_INT32(current_tm.tm_sec, RTCState), - VMSTATE_INT32(current_tm.tm_min, RTCState), - VMSTATE_INT32(current_tm.tm_hour, RTCState), - VMSTATE_INT32(current_tm.tm_wday, RTCState), - VMSTATE_INT32(current_tm.tm_mday, RTCState), - VMSTATE_INT32(current_tm.tm_mon, RTCState), - VMSTATE_INT32(current_tm.tm_year, RTCState), + VMSTATE_INT64(offset, RTCState), VMSTATE_TIMER(periodic_timer, RTCState), VMSTATE_INT64(next_periodic_time, RTCState), - VMSTATE_INT64(next_second_time, RTCState), - VMSTATE_TIMER(second_timer, RTCState), - VMSTATE_TIMER(second_timer2, RTCState), + VMSTATE_TIMER(update_timer, RTCState), + VMSTATE_INT64(next_update_time, RTCState), + VMSTATE_TIMER(alarm_timer, RTCState), + VMSTATE_INT64(next_alarm_time, RTCState),
Hi Yang,this looks like a very nice piece of work, but this unfortunately breaks migration. Also, I'm not sure if the update in progress flag still works. Clients are supposed to wait for UIP=0 before reading the RTC, and an update is supposed to be at least 220 microseconds away when UIP=0.
Also, it would be nice if you could based these patches on the 4-patch series I sent recently that fixes some bugs with interrupts and 12-hour emulation.
There is another aspect of RTC emulation that is missing in the current code; after setting the clock, the next second tick will occur in exactly 500 ms. I have patches to fix this, but it looks like it could be incorporated in your series, too.
Paolo
[Prev in Thread] | Current Thread | [Next in Thread] |