From mboxrd@z Thu Jan  1 00:00:00 1970
From: Avi Kivity <avi@qumranet.com>
Subject: Re: windows acpi time drift
Date: Wed, 19 Mar 2008 10:19:24 +0200
Message-ID: <47E0CC8C.4020901@qumranet.com>
References: <1205881756.21936.21.camel@localhost.localdomain>
	<47E051DB.9070506@codemonkey.ws>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: kvm-devel <kvm-devel@lists.sourceforge.net>
To: Anthony Liguori <anthony@codemonkey.ws>
Return-path: <kvm-devel-bounces@lists.sourceforge.net>
In-Reply-To: <47E051DB.9070506@codemonkey.ws>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/kvm-devel>,
	<mailto:kvm-devel-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=kvm-devel>
List-Post: <mailto:kvm-devel@lists.sourceforge.net>
List-Help: <mailto:kvm-devel-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/kvm-devel>,
	<mailto:kvm-devel-request@lists.sourceforge.net?subject=subscribe>
Sender: kvm-devel-bounces@lists.sourceforge.net
Errors-To: kvm-devel-bounces@lists.sourceforge.net
List-Id: kvm.vger.kernel.org

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/