On 12.01.2010, at 21:52, Blue Swirl wrote:
On Tue, Jan 12, 2010 at 8:34 PM, Alexander Graf agraf@suse.de wrote:
On 12.01.2010, at 20:45, Blue Swirl wrote:
On Tue, Jan 12, 2010 at 11:58 AM, Alexander Graf agraf@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?
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.
Alex