On 13.01.2010, at 20:37, Blue Swirl wrote: > On Wed, Jan 13, 2010 at 7:17 PM, Alexander Graf <ag...@suse.de> wrote: >> >> 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 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.
Don't know, it might be correct :-). Either way, you'd have to do a map similar to the one in the dump you gave above. That should be fairly easy to generate programatically. If you need help to understand interrupt-map properties, feel free to ask. I only finally managed to understand them recently myself. Alex
