qemu-devel
[Top][All Lists]
Advanced

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

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


From: Magnus Christensson
Subject: [Qemu-devel] Re: Seabios: PCI interrupt routing question
Date: Mon, 14 Dec 2009 10:23:39 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Thunderbird/3.0b3

On 12/13/2009 04:12 PM, Kevin O'Connor wrote:
----- 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.
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.





reply via email to

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