Re: [Qemu-devel] [PATCH 3/3] stop the periodic RTC update timer

[Zhang, Yang Z]

> -----Original Message-----
> From: Paolo Bonzini [mailto:address@hidden On Behalf Of Paolo
> Bonzini
> Sent: Monday, January 09, 2012 4:19 PM
> To: Zhang, Yang Z
> Cc: address@hidden; address@hidden; address@hidden; Zhang,
> Xiantao; Shan, Haitao; address@hidden
> 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