Re: windows acpi time drift

[Avi Kivity <avi@qumranet.com>]

Anthony Liguori wrote:
> 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.
>   

The problems with timers are:

- on a loaded machine, several timer ticks may be coalesced together on 
the host side; we need a way to detect overruns
- with one-shot processing, there is inevitable drift.  so we need to 
use periodic timers or to compensate for the drift
- when we have accumulated missed interrupts, we need to inject them
- we may need to coordinate tsc and timer values (like Xen)

the first two problems seem to be resolvable via posix timers 
(timer_create() & friends).  The third issue can be resolved by adding 
an ioctl to queue a bunch of injections (raising and lowering a specific 
line after the ack).  The fourth is probably impossible from userspace 
(and very difficult in the kernel).

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


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