Re: windows acpi time drift

[Anthony Liguori <anthony@codemonkey.ws>]

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

Why don't we just introduce a vm-ioctl interface for a one-shot 
programmable timer?  It could be programmed in userspace, and when it 
fires, we can drop down to userspace with a special exit code.  We could 
then introduce an interrupt queuing mechanism in the kernel specifically 
for timer interrupts as you mention.

That lets us remove the in-kernel PIT, and makes all of our timer 
mechanisms more accurate.  If userspace has a better time mechanism, 
like hrtimer, then it can just use that.  If hrtimer is good enough in 
userspace, then we can contain these new ioctls to the compat-code only.

Regards,

Anthony Liguori



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


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