From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [PATCH] KVM: x86: Avoid busy loops over uninjectable pending APIC timers Date: Sun, 28 Apr 2013 13:23:25 +0300 Message-ID: <20130428102325.GI30504@redhat.com> References: <5144DAC3.7080401@web.de> <20130317084705.GC11223@redhat.com> <517CF6A9.4090500@web.de> <20130428101905.GH30504@redhat.com> <517CF7DC.7010109@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Marcelo Tosatti , kvm To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:19650 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752155Ab3D1KX0 (ORCPT ); Sun, 28 Apr 2013 06:23:26 -0400 Content-Disposition: inline In-Reply-To: <517CF7DC.7010109@web.de> Sender: kvm-owner@vger.kernel.org List-ID: On Sun, Apr 28, 2013 at 12:20:12PM +0200, Jan Kiszka wrote: > On 2013-04-28 12:19, Gleb Natapov wrote: > > 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 > >>>> > >>>> 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. > > But isn't the code still there and working when apicv is absent? > Remove it as a fix for busy loop. It is not a good idea to behave differently on different types of hardware. -- Gleb.