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 17:38:06 +0200 Message-ID: <4D078F5E.60104@redhat.com> References: <901746004.680841292328577685.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> <4D077258.9030500@redhat.com> <1292334036.9367.88.camel@mothafucka.localdomain> <4D0775F1.7000201@redhat.com> <4D078E0A.9@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Glauber Costa , Ulrich Obergfell , kvm@vger.kernel.org, zamsden@redhat.com, mtosatti@redhat.com To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:54827 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755537Ab0LNPiM (ORCPT ); Tue, 14 Dec 2010 10:38:12 -0500 In-Reply-To: <4D078E0A.9@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On 12/14/2010 05:32 PM, Anthony Liguori wrote: >> >>> > 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. > > > Fortunately, we have a very good bytecode interpreter that's > accelerated in the kernel called KVM ;-) We have exactly the same bytecode interpreter under a different name, it's called userspace. If you can afford to make the transition back to the guest for emulation, you might as well transition to userspace. > > Why not have the equivalent of a paravirtual SMM mode where we can > reflect IO exits back to the guest in a well defined way? It could > then implement PM timer in terms of HPET or something like that. More exits. > > We already have a virtual address space that works for most guests > thanks to the TPR optimization. It only works for Windows XP and Windows XP with the /3GB extension. -- error compiling committee.c: too many arguments to function