Re: [Qemu-devel] [PATCH 0/9] PPC NewWorld fixery v3

[Alexander Graf]

On 12.01.2010, at 21:52, Blue Swirl wrote:

> On Tue, Jan 12, 2010 at 8:34 PM, Alexander Graf <address@hidden> wrote:
>> 
>> On 12.01.2010, at 20:45, Blue Swirl wrote:
>> 
>>> On Tue, Jan 12, 2010 at 11:58 AM, Alexander Graf <address@hidden> 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