From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39628) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJsIc-0001Ty-EM for qemu-devel@nongnu.org; Sun, 24 Mar 2013 17:17:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UJsIY-0002V3-T1 for qemu-devel@nongnu.org; Sun, 24 Mar 2013 17:17:54 -0400 Received: from moutng.kundenserver.de ([212.227.17.9]:61676) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJsIY-0002UG-K3 for qemu-devel@nongnu.org; Sun, 24 Mar 2013 17:17:50 -0400 From: Arnd Bergmann Date: Sun, 24 Mar 2013 21:16:28 +0000 References: <1364124760-5794-1-git-send-email-peter.maydell@linaro.org> <20130324191719.GB31138@redhat.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201303242116.28340.arnd@arndb.de> Subject: Re: [Qemu-devel] [PATCH 00/10] Fix versatile_pci (and break versatilepb linux guests!) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: patches@linaro.org, "Michael S. Tsirkin" , Will Deacon , qemu-devel@nongnu.org, Paul Brook , Andreas =?utf-8?q?F=C3=A4rber?= , Aurelien Jarno On Sunday 24 March 2013, Peter Maydell wrote: > Yeah, ideally being able to detect the buggy kernel would be good; > I can't see anything at the controller level that would do though, > and I don't really know enough about PCI to know about generic > PCI stuff that would work. (Why would the OS need to tell the > device anything about its IRQ if it's hardwired?) I think it actually does on versatile and other platforms on which the kernel probes the PCI bus itself, rather than relying on firmware to have resources assigned in advance. IIRC, the PCI_INTERRUPT_LINE pci config space byte (0x3c) is purely informational and used as a way to communicate the interrupt number from the bus scan code (assumed to be a PC BIOS in the PCI spec, but drivers/pci/setup-irq.c in case of versatile+linux) to a device driver. So the kernel should actually write the proper interrupt number in there. In future kernels, this may not necessarily be the hardware number, but today it is. Can you try out what the kernel writes into that register in qemu, with and without my patches? I would expect the numbers to be (64+27) to (64+30), since we linearize the interrupt numbers so that VIC gets 32 through 63 and SIC gets 64 through 95. Arnd