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