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

[Alexander Graf]

On 13.01.2010, at 20:37, Blue Swirl wrote:

> On Wed, Jan 13, 2010 at 7:17 PM, Alexander Graf <address@hidden> wrote:
>> 
>> 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 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