On Sat, Mar 16, 2013 at 09:49:07PM +0100, Jan Kiszka wrote: > From: Jan Kiszka <[email protected]> > > 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. > Just drop coalescing tacking for lapic interrupt. After posted interrupt will be merged __apic_accept_irq() will not longer return coalescing information, so the code will be dead anyway.
> Signed-off-by: Jan Kiszka <[email protected]> > --- > > 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 -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
