From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] KVM: IOAPIC: Fix level-triggered irq injection hang Date: Sat, 05 Jul 2008 11:35:42 +0300 Message-ID: <486F325E.3050502@qumranet.com> References: <1215192195-10359-1-git-send-email-markmc@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Mark McLoughlin Return-path: Received: from il.qumranet.com ([212.179.150.194]:47384 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751523AbYGEIfq (ORCPT ); Sat, 5 Jul 2008 04:35:46 -0400 In-Reply-To: <1215192195-10359-1-git-send-email-markmc@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Mark McLoughlin wrote: > The "remote_irr" variable is used to indicate an interrupt > which has been received by the LAPIC, but not acked. > > In our EOI handler, we unset remote_irr and re-inject the > interrupt if the interrupt line is still asserted. > > However, we do not set remote_irr here, leading to a > situation where if kvm_ioapic_set_irq() is called, then we go > ahead and call ioapic_service(). This means that IRR is > re-asserted even though the interrupt is currently in service > (i.e. LAPIC IRR is cleared and ISR/TMR set) > > The issue with this is that when the currently executing > interrupt handler finishes and writes LAPIC EOI, then TMR is > unset and EOI sent to the IOAPIC. Since IRR is now asserted, > but TMR is not, then when the second interrupt is handled, > no EOI is sent and if there is any pending interrupt, it is > not re-injected. > > This fixes a hang only seen while running mke2fs -j on an > 8Gb virtio disk backed by a fully sparse raw file, with > aliguori "avoid fragmented virtio-blk transfers by copying" > changes. > > Good catch indeed; applied. I think it also fixes the case where the ioapic entry is masked when the eoi occurs. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.