From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NV8Fi-00007p-O7 for qemu-devel@nongnu.org; Wed, 13 Jan 2010 13:47:34 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NV8Fe-0008WI-AB for qemu-devel@nongnu.org; Wed, 13 Jan 2010 13:47:34 -0500 Received: from [199.232.76.173] (port=44907 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NV8Fd-0008WB-QB for qemu-devel@nongnu.org; Wed, 13 Jan 2010 13:47:29 -0500 Received: from mail-pw0-f43.google.com ([209.85.160.43]:63677) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NV8Fd-0000YL-1d for qemu-devel@nongnu.org; Wed, 13 Jan 2010 13:47:29 -0500 Received: by pwj11 with SMTP id 11so3659532pwj.2 for ; Wed, 13 Jan 2010 10:47:27 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <1263297526-13518-1-git-send-email-agraf@suse.de> <9EE70531-F281-4783-800F-EB83C5C66EA2@suse.de> From: Blue Swirl Date: Wed, 13 Jan 2010 18:47:06 +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 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 wrote= : >>>>> 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 ti= me. >>>>> >>>>> This patchset fixes all the PCI config space access and PCI interrupt >>>>> mapping issues I've found on PPC64. Using this and a patched OpenBIOS >>>>> version, I can successfully access IDE devices and was booting a gues= t >>>>> 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 int= o >>>>> Qemu is harder than getting them into OpenBIOS. So I want to wait for >>>>> the review process here first. >>>>> >>>>> Find the OpenBIOS patch at: http://alex.csgraf.de/openbios-ppc-u3.pat= ch >>>> >>>> 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 know= s 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.00000= 001 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scsi-initiator-id: =C2=A0000000= 07 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0compatible: =C2=A070636931.3038= 652c.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.00000000.= 00000000.00000001.f005f1e0.0000000f.00011800.00000000.00000000.00000001.f00= 5f1e0.00000020 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interrupt-map-mask: =C2=A000fff= 800.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 i= s 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? > The UniNorth case is really simple, because it doesn't take any mangling = 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" configurat= ion still ends up being distributed over all 4 interrupts. > > I'm certainly open to more clever ideas. We could of course forget about = all the interrupt mapping and simply put PIC targeted interrupt properties = into each device's node. But I somehow like the map approach better, especi= ally because the "normal" (defined in the interrupt map draft) way of doing= PCI interrupts is to have an interrupt property of size=3D1 which defines = the pin. I should probably read the draft before trying to comment further.