From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NV92U-0000nf-5P for qemu-devel@nongnu.org; Wed, 13 Jan 2010 14:37:58 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NV92P-0000kI-Na for qemu-devel@nongnu.org; Wed, 13 Jan 2010 14:37:57 -0500 Received: from [199.232.76.173] (port=35546 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NV92P-0000kD-EX for qemu-devel@nongnu.org; Wed, 13 Jan 2010 14:37:53 -0500 Received: from mail-px0-f197.google.com ([209.85.216.197]:60919) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NV92O-0006mu-Qt for qemu-devel@nongnu.org; Wed, 13 Jan 2010 14:37:53 -0500 Received: by pxi35 with SMTP id 35so11155091pxi.18 for ; Wed, 13 Jan 2010 11:37:51 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <541F93C1-B72E-4DFB-A4D9-B8F24C963A01@suse.de> References: <1263297526-13518-1-git-send-email-agraf@suse.de> <9EE70531-F281-4783-800F-EB83C5C66EA2@suse.de> <541F93C1-B72E-4DFB-A4D9-B8F24C963A01@suse.de> From: Blue Swirl Date: Wed, 13 Jan 2010 19:37:31 +0000 Message-ID: Subject: Re: [Qemu-devel] [PATCH 0/9] PPC NewWorld fixery v3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: The OpenBIOS Mailinglist , QEMU Developers On Wed, Jan 13, 2010 at 7:17 PM, Alexander Graf wrote: > > On 13.01.2010, at 19:47, Blue Swirl wrote: > >> On Tue, Jan 12, 2010 at 10:11 PM, Alexander Graf wrote: >>> >>> On 12.01.2010, at 21:52, Blue Swirl wrote: >>> >>>> On Tue, Jan 12, 2010 at 8:34 PM, Alexander Graf wrote: >>>>> >>>>> On 12.01.2010, at 20:45, Blue Swirl wrote: >>>>> >>>>>> On Tue, Jan 12, 2010 at 11:58 AM, Alexander Graf wro= te: >>>>>>> I'm trying to get the PPC64 system emulation target working finally= . >>>>>>> While doing so, I ran into several issues, all related to PCI this = time. >>>>>>> >>>>>>> This patchset fixes all the PCI config space access and PCI interru= pt >>>>>>> mapping issues I've found on PPC64. Using this and a patched OpenBI= OS >>>>>>> version, I can successfully access IDE devices and was booting a gu= est >>>>>>> into the shell from IDE using serial console. >>>>>>> >>>>>>> To leverage this patch, you also need a few patches to OpenBIOS. I'= ll >>>>>>> present them to the OpenBIOS list, but in general getting patches i= nto >>>>>>> Qemu is harder than getting them into OpenBIOS. So I want to wait f= or >>>>>>> the review process here first. >>>>>>> >>>>>>> Find the OpenBIOS patch at: http://alex.csgraf.de/openbios-ppc-u3.p= atch >>>>>> >>>>>> About the OpenBIOS patch, could you move the PCI_INT_MAP defines to = a >>>>>> PPC-specific header and make pci_host_set_interrupt_map() contents >>>>>> surrounded by #ifdef CONFIG_PPC (to make it empty function for other >>>>>> arches)? >>>>> >>>>> Well, other archs should be able to use the same code. If OpenBIOS kn= ows how interrupts work for a particular device, it really should tell the = OS about it too IMHO. >>>> >>>> I'm not so sure. Here's an example of a Sparc64 interrupt-map: >>>> >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0Node 0xf005f9d4 >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bus-range: =C2=A000000001.000= 00001 >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scsi-initiator-id: =C2=A00000= 0007 >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0compatible: =C2=A070636931.30= 38652c.35303030.00706369 >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A066mhz-capable: >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fast-back-to-back: >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0devsel-speed: =C2=A000000001 >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0class-code: =C2=A000060400 >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0revision-id: =C2=A000000011 >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0device-id: =C2=A000005000 >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vendor-id: =C2=A00000108e >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interrupt-map: >>>> 00010800.00000000.00000000.00000001.f005f1e0.00000021.00011000.0000000= 0.00000000.00000001.f005f1e0.0000000f.00011800.00000000.00000000.00000001.f= 005f1e0.00000020 >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interrupt-map-mask: =C2=A000f= ff800.00000000.00000000.00000007 >>> >>> >>> This translates to: >>> >>> Interrupt PIN A on dev 00010800 -> INT 0x21 >>> Interrupt PIN A on dev 00011000 -> INT 0x0f >>> Interrupt PIN A on dev 00011800 -> INT 0x20 >>> >>> What does the corresponding code in OpenBIOS do to figure out which IRQ= is routed where? >> >> Currently there isn't anything, so something may be better than >> nothing. Would your code produce correct interrupt-map then also for >> Sparc64? > > Depends on how your PCI bridge maps interrupts. What does qemu's pci inte= rrupt map function for your pci bridge look like? /* The APB host has an IRQ line for each IRQ line of each slot. */ static int pci_apb_map_irq(PCIDevice *pci_dev, int irq_num) { return ((pci_dev->devfn & 0x18) >> 1) + irq_num; } This may be bogus though. > >> >>> The UniNorth case is really simple, because it doesn't take any manglin= g into account. Usually PCI bridges also assign pins differently depending = on the port the card is plugged into, so an "all devices on PIN A" configur= ation still ends up being distributed over all 4 interrupts. >>> >>> I'm certainly open to more clever ideas. We could of course forget abou= t all the interrupt mapping and simply put PIC targeted interrupt propertie= s into each device's node. But I somehow like the map approach better, espe= cially because the "normal" (defined in the interrupt map draft) way of doi= ng PCI interrupts is to have an interrupt property of size=3D1 which define= s the pin. >> >> I should probably read the draft before trying to comment further. > > http://playground.sun.com/1275/practice/imap/imap0_9d.pdf Thanks.