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:12:05 +0200 Message-ID: <4D078945.7080807@redhat.com> References: <1656215019.700771292337892260.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, zamsden@redhat.com, mtosatti@redhat.com, Glauber Costa To: Ulrich Obergfell Return-path: Received: from mx1.redhat.com ([209.132.183.28]:28901 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758772Ab0LNPMJ (ORCPT ); Tue, 14 Dec 2010 10:12:09 -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 oBEFC9DJ026769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 14 Dec 2010 10:12:09 -0500 In-Reply-To: <1656215019.700771292337892260.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 12/14/2010 04:44 PM, Ulrich Obergfell wrote: > > > > 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? > > Avi, > > the idea is to use the '-kvm-pmtmr' option (in code part 4) only > with guests that do not enable the 'timer carry interrupt'. Guests > that need to enable the 'timer carry interrupt' should rather use > the PM Timer emulation in qemu userspace (i.e. they should not be > started with this option). If a guest is accidentally started with > this option, the in-kernel PM Timer (in code part 1) detects if > the guest attempts to enable the 'timer carry interrupt' and falls > back to PM Timer emulation in qemu userspace (in-kernel PM Timer > disables itself automatically). So, this is not a combination of > in-kernel PM Timer register emulation and qemu userspace PM Timer > interrupt emulation. > We really try to avoid guest specific parameters. Having to decide if the guest has virtio is bad enough, but going into low level details like that is really bad. The host admin might not even know what operating systems its guests run. A guest might even dual boot two different operating systems. -- error compiling committee.c: too many arguments to function