Dong, Eddie wrote:
>>
>> While this improves throughput, doesn't it decrease responsiveness?
>> Suppose the guest is sleeping and there is no activity except
>> for lapic
>> interrupts. Won't the wakeup get deferred indefinitely?
>>
>
> didn't catch here. do u mean the guest is in HLT ? There is hole here
> for HLT case.
> Will fix.
>
>
Yes, I meant HLT.
>>> +void kvm_pt_update_irq(struct kvm_vcpu *vcpu)
>>> +{
>>> + struct kvm_lapic *apic = vcpu->apic;
>>> +
>>> + if (apic && atomic_read(&apic->timer.pending) > 0) {
>>>
>>>
>> Extra braces. Also this smells like a race. What if timer.pending
>> is updated just after this?
>>
>
> kvm_pt_update_irq is within intr_assist where host IRQ is disabled.
> It can be updated only after we return to guest.
>
What if it runs on another cpu?
>>>
>> How about "kvm_inject_pending_timer_irqs"
>>
>
> Sure. But we will have PIT too, so maybe kvm_inject_apic_timer_irqs?
>
>
Maybe kvm_inject_pending_timer_irqs() can call the apic and pit
variants, so we have just on hook in vmx.c and svm.c?
>
> BTW, can u rebase the branch? I saw some error in today's branch.
>
> Will send patch after you rebased.
>
Okay. I am testing out kvm-34 now, will start rebase shortly after. It
will take some time as there have been quite a few changes.
--
error compiling committee.c: too many arguments to function
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
kvm-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel
