From: Beth Kon <eak@us.ibm.com>
To: Avi Kivity <avi@redhat.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH 4/4] Userspace changes for KVM HPET (v3)
Date: Tue, 12 May 2009 10:25:17 -0400 [thread overview]
Message-ID: <4A0986CD.20601@us.ibm.com> (raw)
In-Reply-To: <4A093B49.7010609@redhat.com>
Avi Kivity wrote:
> Beth Kon wrote:
>> Signed-off-by: Beth Kon <eak@us.ibm.com>
>>
>>
>> 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?
next prev parent reply other threads:[~2009-05-12 14:24 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-11 17:29 [PATCH 1/4] BIOS changes for configuring irq0->inti2 override (v3) Beth Kon
2009-05-11 17:29 ` [PATCH 2/4] Userspace " Beth Kon
2009-05-12 9:53 ` Gleb Natapov
2009-05-12 10:22 ` Avi Kivity
2009-05-12 10:52 ` Gleb Natapov
2009-05-12 13:20 ` [PATCH 2/4] Userspace changes for configuring irq0->inti2override (v3) Beth Kon
2009-05-12 13:37 ` Gleb Natapov
2009-05-12 13:29 ` Beth Kon
2009-05-11 17:29 ` [PATCH 3/4] BIOS changes for KVM HPET (v3) Beth Kon
2009-05-11 17:29 ` [PATCH 4/4] Userspace " Beth Kon
2009-05-12 9:03 ` Avi Kivity
2009-05-12 14:25 ` Beth Kon [this message]
2009-05-12 16:27 ` Beth Kon
2009-05-13 7:48 ` Avi Kivity
2009-05-13 7:50 ` Avi Kivity
2009-05-12 9:57 ` [PATCH 1/4] BIOS changes for configuring irq0->inti2 override (v3) Gleb Natapov
2009-05-12 13:59 ` [PATCH 1/4] BIOS changes for configuring irq0->inti2 override(v3) Beth Kon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A0986CD.20601@us.ibm.com \
--to=eak@us.ibm.com \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.