From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57027) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBQ2a-0003lM-9g for qemu-devel@nongnu.org; Tue, 11 Sep 2012 08:58:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TBQ2T-0005GM-5P for qemu-devel@nongnu.org; Tue, 11 Sep 2012 08:58:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59849) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBQ2S-0005G3-UC for qemu-devel@nongnu.org; Tue, 11 Sep 2012 08:58:01 -0400 Message-ID: <504F354F.7070202@redhat.com> Date: Tue, 11 Sep 2012 15:57:51 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1347240466-6152-1-git-send-email-mmogilvi_qemu@miniinfo.net> <1347240466-6152-6-git-send-email-mmogilvi_qemu@miniinfo.net> <504DAB38.4000407@redhat.com> <504DAE47.8090607@web.de> <504DB061.6060209@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v5 5/6] i8259: fix so that dropping IRQ level always clears the interrupt request List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Maciej W. Rozycki" Cc: Paolo Bonzini , Jan Kiszka , Matthew Ogilvie , qemu-devel@nongnu.org On 09/10/2012 04:09 PM, Maciej W. Rozycki wrote: > >> > No, this is about the PIC, not the CPU interrupt inputs. >> >> I see, the interrupt is still sent to the processor; but IRR reflects >> that status of the input line, not a "pending interrupt" status. > > Not really, this is still a "pending interrupt" status. > > For level-triggered inputs the state of IRR bits do indeed follow the > respective IRx inputs (taking the IMR into account). For edge-triggered > inputs the relevant IRR bit is set by a leading edge on its corresponding > IRx input and cleared when the interrupt is acknowledged (either with an > INTA bus cycle or by a data read bus cycle issued to the PIC armed with an > OCW3 that has had the POLL command bit set) OR with a trailing edge on IRx > (again, all this takes the IMR into account). At this point another > leading edge is required for the IRR bit to be set again, that is merely > keeping the IRx input's level active won't trigger another interrupt. Ok, thanks, that explains it for me. -- error compiling committee.c: too many arguments to function