From: Jan Kiszka <jan.kis...@siemens.com>
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.kis...@siemens.com>
---
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
