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

[Alexander Graf]

On 13.01.2010, at 19:47, Blue Swirl wrote:

> On Tue, Jan 12, 2010 at 10:11 PM, Alexander Graf <address@hidden> wrote:
>> 
>> 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?
> 
> 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