[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH]MC146818 RTC: Get correct guest time when irq co
From: |
address@hidden |
Subject: |
Re: [Qemu-devel] [PATCH]MC146818 RTC: Get correct guest time when irq coalesced |
Date: |
Tue, 27 Sep 2016 11:13:55 +0800 |
>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.
- Re: [Qemu-devel] [PATCH]MC146818 RTC: coordinate guest clock base to destination host after migration, (continued)
- Re: [Qemu-devel] [PATCH]MC146818 RTC: coordinate guest clock base to destination host after migration, Paolo Bonzini, 2016/09/21
- Re: [Qemu-devel] [PATCH]MC146818 RTC: coordinate guest clock base to destination host after migration, address@hidden, 2016/09/22
- [Qemu-devel] [PATCH v2]MC146818 RTC: coordinate guest clock base to destination host after migration, address@hidden, 2016/09/25
- Re: [Qemu-devel] [PATCH v2]MC146818 RTC: coordinate guest clock base to destination host after migration, Paolo Bonzini, 2016/09/26
- [Qemu-devel] [PATCH v3]MC146818 RTC: coordinate guest clock base to destination host after migration, address@hidden, 2016/09/26
- Re: [Qemu-devel] [PATCH v3]MC146818 RTC: coordinate guest clock base to destination host after migration, Paolo Bonzini, 2016/09/26
- [Qemu-devel] [PATCH v4]MC146818 RTC: coordinate guest clock base to destination host after migration, address@hidden, 2016/09/26
- Re: [Qemu-devel] [PATCH v4]MC146818 RTC: coordinate guest clock base to destination host after migration, Paolo Bonzini, 2016/09/26
- [Qemu-devel] [PATCH]MC146818 RTC: Get correct guest time when irq coalesced, address@hidden, 2016/09/26
- Re: [Qemu-devel] [PATCH]MC146818 RTC: Get correct guest time when irq coalesced, Paolo Bonzini, 2016/09/26
- Re: [Qemu-devel] [PATCH]MC146818 RTC: Get correct guest time when irq coalesced,
address@hidden <=