After some research of time drift while using window windows acpi hal I
discovered it uses the ... rtc timer as a source clock.
Not the apic, acpi nor the pit. The acpi timer is not used by the time
keeping clock, the apic & pit timer irqs are masked.
In order to fix the time drift we need to fix the rtc emulation.
The problem is that like the pit and the apic timers in userspace, the
rtc also has inaccurate timer, thus leading to irq coalescing before
getting acknowledged by the guest interrupt controller.
We have two options:
1. Bring another device to the kernel
- It's a simple device
- It will make the rtc clock more accurate (hrtimer)
- Easy time drift fix like apic/pic
- It has very minor performance improvment of canceling the
need to go to userspace after vmexit, thus not syncing vmcs.
But it's only 15msec * 2 rate.
but
- both the pit & rtc are somehow code duplications from
userspace. Both need more accurate timer + interface to
detect irq acks by the pic/apic.
2. The other option is to have an accurate userspace timer (userspace
hrtimer exist >= 2.6.24) and to add interface to pic/apic to queue
pending irqs by the pit/rtc.
The pending queue can be a simple atomic counter per irq.
Note that we also need support for older host kernels.
Before implementing yet another in-kernel device I like to hear
opinions.
Regards,
Dor.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
