From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48457 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PfBDJ-0004e2-DL for qemu-devel@nongnu.org; Tue, 18 Jan 2011 08:03:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PfBDH-0004Xu-PJ for qemu-devel@nongnu.org; Tue, 18 Jan 2011 08:03:09 -0500 Received: from mx1.redhat.com ([209.132.183.28]:15477) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PfBDH-0004Xg-Ar for qemu-devel@nongnu.org; Tue, 18 Jan 2011 08:03:07 -0500 Message-ID: <4D358F81.6030202@redhat.com> Date: Tue, 18 Jan 2011 14:02:57 +0100 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 8/8] ahci: fix !msi interrupts References: <1292879604-22268-1-git-send-email-agraf@suse.de> <1292879604-22268-9-git-send-email-agraf@suse.de> <4D34542D.7080301@siemens.com> <4D3467B9.3070207@suse.de> <4D346834.8000903@siemens.com> <4D3468A0.3060709@suse.de> <4D346C31.8060300@siemens.com> <4D346F5B.7090502@suse.de> <4D35587F.3050503@redhat.com> <2006A7EF-07DC-4DAA-B6ED-88D24D6B7978@suse.de> In-Reply-To: <2006A7EF-07DC-4DAA-B6ED-88D24D6B7978@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Kevin Wolf , Jan Kiszka , Joerg Roedel , qemu-devel Developers , Sebastian Herbszt Hi, >> edge triggered interrupts wouldn't though. > > The code change doesn't change anything for edge triggered > interrupts - they work fine. Only !msi (== level) ones are broken. apic irqs can be both edge and level triggered too ... >> That re-trigger smells like you are not clearing the interrupt line >> where you should. For starters try calling ahci_check_irq() after >> guest writes to PORT_IRQ_STAT. > > The problem happened when I had the following: > > ahci irq bits = 0 > > ahci irq bits = 1 | 2 > irq line trigger > guest clears 1 > ahci bits = 2 > > On normal hardware, the high state of the irq line would simply trigger another interrupt in the guest when it gets ACKed on the LAPIC. Somehow it doesn't get triggered here. I don't see why clearing the interrupt line would help? It's not what real hardware would do, no? I think the guest and the ahci emulation simply disagree on whenever a irq is pending or not. Guest thinks it has cleared the IRQ, but the code path it has taken didn't trigger ahci_irq_lower(). It is probably related to how the per-port and global irq status play together. It isn't covered very well in the specs :-( If an interrupt condition happens a bit in pr->irq_stat will be set. When the contition is enabled the port bit in irqstatus will be set, which in turn will trigger an irq. That is the easy part. Now the guest checks irqstatus to find the port, then checks pr->irq_stat to find the condition, acks it by clearing the bits it has seen in pr->irq_stat. What does happen with the port bit in irqstatus now? Will it be cleared automatically? Must the guest clear it explicitly? What happens in case another irq condition happened which the guest didn't ack (yet), will the guest be able to clear the bit? cheers, Gerd