Re: windows acpi time drift

[Dor Laor <dor.laor@gmail.com>]

On Wed, 2008-03-19 at 01:09 +0200, Dor Laor wrote:
> 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.

Hmm, when doing multimedia, windows increases the frequency of rtc from
64HZ to 1024HZ, thus in-kernel device will save 2048 user-space exits.
This might be a real improvement - small but measurable.

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