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

[Paolo Bonzini <pbonzini@redhat.com>]

On 01/10/2012 07:37 AM, Zhang, Yang Z wrote:
>> 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.

This is incorrect, for two reasons.  First, the UIP is in the spec, and 
we have to implement it.  Second, reading the clock is not atomic, and 
waiting for UIP=0 gives you 220 microseconds during which you know that 
the read will appear atomic.

>> 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?

I don't know. :)

>> 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?

It means that the (not externally visible) millisecond value is set to 
500 when you modify the current time of the RTC.  The next update of the 
clock will happen exactly 500 ms after you reset bit 7 of register B.

Paolo