Re: [Qemu-devel] [PATCH]MC146818 RTC: Get correct guest time when irq coalesced

[address@hidden]

>No, it's not seconds.  It depends on the interval of the periodic interrupt.
> 
>In any case this approach is not acceptable, unfortunately; it causes
>the time to go backwards for the guest as soon as an interrupt is coalesced.
>
>What is the guest that you're seeing issues with?

Yes, it's length depend on settings in register A. Sorry for my mistake,  but 
the issue
ought to be still exist, which make guest clock runs ahead of time.
We are testing winxp. Mechanism of windows, at least winxp, is reading cmos 
once for 
initial time while boot time, then set up period interrupt trigger. 
After initialization, windows will run clock in response of period interrupt 
received, 
besides that it also read cmos seldomly for synchronization or something else.
So if period interrupt is queued in qemu, clock in windows will not run. When 
those
interrupts injected hurrily, windows clock catch up with guest virtual time 
quickly.

------------t1-------------------t2--t3-----------------t4-------------
                   ^                             ^   ^                          
  ^
                    |                              |    inject finish         
final time driven by intrs
             timer stall       read cmos
    
For example,  when guest virtual time goes to t1, qemu is busy in some heavy job
and cause qemu timer delayed.  when t2, qemu finish jobs and is free to run 
timers.
At this time, all period interrupts between t1 and t2 will be generated and 
queued 
in irq_coalesced. Those intrs will be injected  a little faster but one by one 
into guest. 
Normally, they will be all injected completely at t3. After all timers are 
proceeded, 
guest also have chance to run. if it read cmos time at that moment, it will 
read t2, 
but actuallly it's clock is now at t1, any way, it trust rtc hardware, so it 
set its clock to
t2, then it continue to drive clock by period interrupts, because there are 
still lots of 
queued interrupts injecting, so guest's clock runs quite quickly. When time 
goes to 
t3, all interrupt injected, but guest's clock already goes to t4, where t4-t3 
equal t2-t1.
    
According to figure above, because:         t2-t1=t4-t2        t3-t2 <<< 
t4-t2so:        t3 <<< t4
That is to say,  guest goes ahead of time.