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

[Blue Swirl <blauwirbel@gmail.com>]

On Wed, Jan 13, 2010 at 7:17 PM, Alexander Graf <agraf@suse.de> wrote:
>
> On 13.01.2010, at 19:47, Blue Swirl wrote:
>
>> On Tue, Jan 12, 2010 at 10:11 PM, Alexander Graf <agraf@suse.de> wrote:
>>>
>>> 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?
>>
>> 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.

>
>>
>>> 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

Thanks.