Re: [PATCH 4/4] Userspace changes for KVM HPET (v3)

[Beth Kon <eak@us.ibm.com>]

Beth Kon wrote:
> 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?
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