[Qemu-devel] Re: Seabios: PCI interrupt routing question

[Magnus Christensson <mch@virtutech.com>]

On 12/13/2009 04:12 PM, Kevin O'Connor wrote:
> ----- Forwarded message from Gleb Natapov<gleb@redhat.com>  -----
>
> From: Gleb Natapov<gleb@redhat.com>
> To: Kevin O'Connor<kevin@koconnor.net>
> Date: Sun, 13 Dec 2009 17:07:48 +0200
> Subject: Re: [mch@virtutech.com: [coreboot] Seabios: PCI interrupt routing
> 	question]
>
> On Thu, Dec 10, 2009 at 08:55:11AM -0500, Kevin O'Connor wrote:
>    
>> FYI.
>>
>> ----- Forwarded message from Magnus Christensson<mch@virtutech.com>  -----
>>
>> From: Magnus Christensson<mch@virtutech.com>
>> To: coreboot@coreboot.org
>> Date: Fri, 27 Nov 2009 09:13:02 +0100
>> Subject: [coreboot] Seabios: PCI interrupt routing question
>>
>> Hi,
>>
>> I have a question about the PCI INTx pin interrupt routing in Seabios.
>>
>> Specifically, what does the pci_slot_get_pirq function do? It looks like
>> it assigns different interrupt numbers to devices depending on their
>> device number.
>>
>>      
> This function implement the same logic as pci_swizzle_interrupt_pin() in
> Linux kernel. This logic defines how PCI bridge connects INTx of each
> devices behind it to system board interrupt line and it is part of PCI
> spec (page 30 of PCI3.0 spec). Note that the function return pin, not
> interrupt line. To get interrupt line we look into pci_irqs[] array.
>    
The swizzling of INTx-pins happens in PCI-to-PCI bridges. But it looks 
like the pci_slot_get_pirq function is applied to all devices, including 
those on the top-level bus that are not behind any PCI-to-PCI bridge. 
Further, the function only looks at device (slot) and doesn't care where 
the device is in the PCI hierarchy.

>    
>> But the interrupt routing in the southbridge maps a given INTx to the same
>> interrupt number regardless of the device number (that mapping is
>> initialized by the code with the "activate irq remapping in PIIX" comment).
>>
>> To me, this looks like the INTERRUPT_LINE would be set to a value that
>> does not match the actual interrupt routing (if (dev&  3) != 0).
>>
>>      
> The code is correct if QEMU does interrupt swizzling on PIIX3 chipset
> level. The code in incorrect if QEMU doesn't. Swizzling like this is
> done by PCI-to-PCI bridges according to PCI spec, root bridge doesn't do
> it AFAIK, so code looks suspicious, but not because of the reason stated
> above.
>    
Yes, if the QEMU emulation of PIIX3 does swizzling on bus #0 (which I 
don't think happens in hardware), then the code would be correct (for 
running on QEMU).

M.