From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [RFC 0/4] KVM in-kernel PM Timer implementation Date: Tue, 14 Dec 2010 09:32:26 -0600 Message-ID: <4D078E0A.9@codemonkey.ws> 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> 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: Avi Kivity Return-path: Received: from mail-qy0-f174.google.com ([209.85.216.174]:52505 "EHLO mail-qy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757644Ab0LNPc1 (ORCPT ); Tue, 14 Dec 2010 10:32:27 -0500 Received: by qyj19 with SMTP id 19so4937215qyj.19 for ; Tue, 14 Dec 2010 07:32:27 -0800 (PST) In-Reply-To: <4D0775F1.7000201@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 12/14/2010 07:49 AM, Avi Kivity wrote: > 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. Fortunately, we have a very good bytecode interpreter that's accelerated in the kernel called KVM ;-) 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. We already have a virtual address space that works for most guests thanks to the TPR optimization. Regards, Anthony Liguori