> -----Original Message----- > From: Paolo Bonzini [mailto:paolo.bonzini@xxxxxxxxx] On Behalf Of Paolo > Bonzini > Sent: Monday, January 09, 2012 4:19 PM > To: Zhang, Yang Z > Cc: qemu-devel@xxxxxxxxxx; avi@xxxxxxxxxx; aliguori@xxxxxxxxxx; Zhang, > Xiantao; Shan, Haitao; kvm@xxxxxxxxxxxxxxx > Subject: Re: [PATCH 3/3] stop the periodic RTC update timer > > 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. You are right. In next version, I will add the qemu version check. > 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. Hardware need a period time to update clock and it would not provide the right value during the update. So it uses UIP to notify the software doesn't believe the value if the UIP is set. For emulation, you can read RTC at any time and it always gives you the right value. So there is no need to emulate UIP. > 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. When it will be check in? > 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. I do not quite understand it. What does "setting the clock" mean? And what is the next second tick? > Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
