On 13.01.2010, at 19:47, Blue Swirl wrote: > On Tue, Jan 12, 2010 at 10:11 PM, Alexander Graf <ag...@suse.de> wrote: >> >> On 12.01.2010, at 21:52, Blue Swirl wrote: >> >>> On Tue, Jan 12, 2010 at 8:34 PM, Alexander Graf <ag...@suse.de> wrote: >>>> >>>> On 12.01.2010, at 20:45, Blue Swirl wrote: >>>> >>>>> On Tue, Jan 12, 2010 at 11:58 AM, Alexander Graf <ag...@suse.de> 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 time. >>>>>> >>>>>> 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 guest >>>>>> 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 into >>>>>> 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.patch >>>>> >>>>> 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 knows >>>> 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: >>> >>> Node 0xf005f9d4 >>> bus-range: 00000001.00000001 >>> scsi-initiator-id: 00000007 >>> compatible: 70636931.3038652c.35303030.00706369 >>> 66mhz-capable: >>> fast-back-to-back: >>> devsel-speed: 00000001 >>> class-code: 00060400 >>> revision-id: 00000011 >>> device-id: 00005000 >>> vendor-id: 0000108e >>> interrupt-map: >>> 00010800.00000000.00000000.00000001.f005f1e0.00000021.00011000.00000000.00000000.00000001.f005f1e0.0000000f.00011800.00000000.00000000.00000001.f005f1e0.00000020 >>> interrupt-map-mask: 00fff800.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 interrupt map function for your pci bridge look like? > >> 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" >> configuration 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, especially >> because the "normal" (defined in the interrupt map draft) way of doing PCI >> interrupts is to have an interrupt property of size=1 which defines the pin. > > I should probably read the draft before trying to comment further. http://playground.sun.com/1275/practice/imap/imap0_9d.pdf Alex
