From: Jan Kiszka <jan.kiszka@xxxxxxxxxxx> If the guest didn't take the last APIC timer interrupt yet and generates another one on top, e.g. via periodic mode, we do not block the VCPU even if the guest state is halted. The reason is that apic_has_pending_timer continues to return a non-zero value. Fix this busy loop by taking the IRR content for the LVT vector in apic_has_pending_timer into account. Signed-off-by: Jan Kiszka <jan.kiszka@xxxxxxxxxxx> --- Not a critical issue, we are looping fully interruptible, but it's ugly to do so IMHO. arch/x86/kvm/lapic.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index a8e9369..658abf5 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -1473,7 +1473,9 @@ int apic_has_pending_timer(struct kvm_vcpu *vcpu) struct kvm_lapic *apic = vcpu->arch.apic; if (kvm_vcpu_has_lapic(vcpu) && apic_enabled(apic) && - apic_lvt_enabled(apic, APIC_LVTT)) + apic_lvt_enabled(apic, APIC_LVTT) && + !apic_test_vector(apic_lvt_vector(apic, APIC_LVTT), + apic->regs + APIC_IRR)) return atomic_read(&apic->lapic_timer.pending); return 0; -- 1.7.3.4 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
