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
