From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC 0/4] KVM in-kernel PM Timer implementation Date: Tue, 14 Dec 2010 15:49:37 +0200 Message-ID: <4D0775F1.7000201@redhat.com> References: <901746004.680841292328577685.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> <4D077258.9030500@redhat.com> <1292334036.9367.88.camel@mothafucka.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Ulrich Obergfell , kvm@vger.kernel.org, zamsden@redhat.com, mtosatti@redhat.com To: Glauber Costa Return-path: Received: from mx1.redhat.com ([209.132.183.28]:2533 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759029Ab0LNNtl (ORCPT ); Tue, 14 Dec 2010 08:49:41 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oBEDnfFk008719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 14 Dec 2010 08:49:41 -0500 In-Reply-To: <1292334036.9367.88.camel@mothafucka.localdomain> Sender: kvm-owner@vger.kernel.org List-ID: On 12/14/2010 03:40 PM, Glauber Costa wrote: > > > > What is the motivation for this? Are there any important guests that > > use the pmtimer? > Avi, > > All older RHEL and Windows, for example, would benefit for this. They only benefit from it because we don't provide HPET. If we did, the guests would use HPET in preference to pmtimer, since HPET is so much better than pmtimer (yet still sucks in an absolute sense). > > If anything I'd expect hpet or the Microsoft synthetic timers to be a > > lot more important. > > True. But also a lot more work. > Implementing just the pm timer counter - not the whole of it - in > kernel, gives us a lot of gain with not very much effort. Patch is > pretty simple, as you can see, and most of it is even code to turn it > on/off, etc. > Partial emulation is not something I like since it causes a fuzzy kernel/user boundary. In this case, transitioning to userspace when interrupts are enabled doesn't look so hot. Are you sure all guests that benefit from this don't enable the pmtimer interrupt? What about the transition? Will we have a time discontinuity when that happens? What I'd really like to see is this stuff implemented in bytecode, unfortunately that's a lot of work which will be very hard to upstream. -- error compiling committee.c: too many arguments to function