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/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
