From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 4/5] Userspace changes for KVM HPET (v6) Date: Sun, 14 Jun 2009 11:55:09 +0300 Message-ID: <4A34BAED.1030302@redhat.com> References: <1244771206-19872-1-git-send-email-eak@us.ibm.com> <1244771206-19872-4-git-send-email-eak@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Beth Kon Return-path: Received: from mx2.redhat.com ([66.187.237.31]:50427 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753655AbZFNIzM (ORCPT ); Sun, 14 Jun 2009 04:55:12 -0400 In-Reply-To: <1244771206-19872-4-git-send-email-eak@us.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: Beth Kon wrote: > The big change here is handling of enabling/disabling of hpet legacy mode. When hpet enters > legacy mode, the spec says that the pit stops generating interrupts. In practice, we want to > stop the pit periodic timer from running because it is wasteful in a virtual environment. > > We also have to worry about the hpet leaving legacy mode (which, at least in linux, happens > only during a shutdown or crash). At this point, according to the hpet spec, PIT interrupts > need to be reenabled. For us, it means the PIT timer needs to be restarted. > > This patch handles this situation better than the previous version by coming closer to > just disabling PIT interrupts. It allows the PIT state to change if the OS modifies it, > even while PIT is disabled, but does not allow a pit timer to start. Then if HPET > legacy mode is disabled, whatever the PIT state is at that point, the PIT timer is > restarted accordingly. > > Given that this depends on the ABI-breaking patch 5, I've dropped it too. -- error compiling committee.c: too many arguments to function