[Qemu-devel] Seabios: PCI interrupt routing question

[Qemu-devel] Seabios: PCI interrupt routing question

[Kevin O'Connor]

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

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

--
			Gleb.

----- End forwarded message -----

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

[Magnus Christensson]

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.