From mboxrd@z Thu Jan 1 00:00:00 1970 From: Beth Kon Subject: Re: [PATCH 4/4] Userspace changes for KVM HPET (v3) Date: Tue, 12 May 2009 12:27:07 -0400 Message-ID: <4A09A35B.5030908@us.ibm.com> References: <1242062986-29383-1-git-send-email-eak@us.ibm.com> <1242062986-29383-4-git-send-email-eak@us.ibm.com> <4A093B49.7010609@redhat.com> <4A0986CD.20601@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: Avi Kivity Return-path: Received: from e5.ny.us.ibm.com ([32.97.182.145]:34750 "EHLO e5.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751113AbZELQ0V (ORCPT ); Tue, 12 May 2009 12:26:21 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n4CGLEmN016675 for ; Tue, 12 May 2009 12:21:14 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n4CGQMhQ144304 for ; Tue, 12 May 2009 12:26:22 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n4CGOOug026916 for ; Tue, 12 May 2009 12:24:24 -0400 In-Reply-To: <4A0986CD.20601@us.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: Beth Kon wrote: > Avi Kivity wrote: >> Beth Kon wrote: >>> Signed-off-by: Beth Kon >>> >>> >>> diff --git a/hw/hpet.c b/hw/hpet.c >>> index c7945ec..100abf5 100644 >>> --- a/hw/hpet.c >>> +++ b/hw/hpet.c >>> @@ -30,6 +30,7 @@ >>> #include "console.h" >>> #include "qemu-timer.h" >>> #include "hpet_emul.h" >>> +#include "qemu-kvm.h" >>> >>> //#define HPET_DEBUG >>> #ifdef HPET_DEBUG >>> @@ -48,6 +49,28 @@ uint32_t hpet_in_legacy_mode(void) >>> return 0; >>> } >>> >>> +static void hpet_legacy_enable(void) >>> +{ >>> + if (qemu_kvm_pit_in_kernel()) { >>> + kvm_kpit_disable(); >>> + dprintf("qemu: hpet disabled kernel pit\n"); >>> + } else { >>> + hpet_pit_disable(); >>> + dprintf("qemu: hpet disabled userspace pit\n"); >>> + } >>> +} >>> + >>> +static void hpet_legacy_disable(void) >>> +{ >>> + if (qemu_kvm_pit_in_kernel()) { >>> + kvm_kpit_enable(); >>> + dprintf("qemu: hpet enabled kernel pit\n"); >>> + } else { >>> + hpet_pit_enable(); >>> + dprintf("qemu: hpet enabled userspace pit\n"); >>> + } >>> +} >>> >> I think it's better to move these into hpet_pit_enable() and >> hpet_pit_enable(). This avoids changing the calls below, and puts >> pit stuff in i8254.c instead of hpet.c. >> >> Might also need to be called from hpet_load(); probably a problem in >> upstream as well. >> > My assumption about hpet_load was that the correct pit state would be > established via pit_load (since all saves/loads are done together). > But when I wrote this, I was thinking only about the userspace pit > (for qemu). I'm not sure how the "load" concept applies to kernel > state. Do I need to explicitly re-enable or disable the kernel pit > during load? Looking further at the code, it looks like kvm_pit_load should take care of this. Agree? > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html