On Sun, Apr 28, 2013 at 12:15:05PM +0200, Jan Kiszka wrote: > On 2013-03-17 09:47, Gleb Natapov wrote: > > 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. > > If I understood the follow-up discussion correctly, we aren't dropping > de-coalescing support yet. So how to proceed with this fix here? > We do. It does not work if you run on CPU with apicv support already.
> Jan > > > > >> 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. > > -- 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
