qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Seabios: PCI interrupt routing question


From: Kevin O'Connor
Subject: [Qemu-devel] Seabios: PCI interrupt routing question
Date: Sun, 13 Dec 2009 10:12:49 -0500
User-agent: Mutt/1.5.19 (2009-01-05)

----- Forwarded message from Gleb Natapov <address@hidden> -----

From: Gleb Natapov <address@hidden>
To: Kevin O'Connor <address@hidden>
Date: Sun, 13 Dec 2009 17:07:48 +0200
Subject: Re: address@hidden: [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 <address@hidden> -----
> 
> From: Magnus Christensson <address@hidden>
> To: address@hidden
> 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 -----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]