Questions about IO-APIC

[Udo Steinberg]

On Sat, 28 Jul 2012 08:29:31 -0800 Chen Tian (CT) wrote:

CT> So I should use the interrupt pin field at offset 0x3c to find out which
CT> PCI link the device uses.

Yes, but the offset of the interrupt pin ix 0x3d.

CT> Can I use this value directly to search IO-APIC
CT> GSI in _PRT blocks?  I read some article that says this value may be local
CT> to PCI device, and it may be remapped by motherboard to another PCI link
CT> number through something like daisy chain type of mapping. For example, PCI
CT> slot 1's INTA# uses INTA#,  while PCI slot 2's INTA# actually uses INTB#.
CT>  Is this true? If so,  I think I need to handle this mapping before search
CT> _PRT blocks, right?

The _PRT method is defined in the ACPI specification as follows:

Field   Type     Description
Address DWORD    The address of the device (uses the same format as _ADR).
Pin     BYTE     The PCI pin number of the device (0­INTA, 1­INTB, 2­INTC, 3­INTD).
Source  NamePath Name of the device that allocates the interrupt to which the above pin is
        Or       connected. The name can be a fully qualified path, a relative path, or a simple
        BYTE     name segment that utilizes the namespace search rules. Note: This field is a
                 NamePath and not a String literal, meaning that it should not be surrounded by
                 quotes. If this field is the integer constant Zero (or a BYTE value of 0), then the
                 interrupt is allocated from the global interrupt pool.
Source  DWORD    Index that indicates which resource descriptor in the resource template of the
Index            device pointed to in the Source field this interrupt is allocated from. If the
                 Source field is the BYTE value zero, then this field is the global system
                 interrupt number to which the pin is connected.

Once you've found the PCI device in the ACPI namespace, you need to look at
the "Source" field to see which upstream device a PCI pin is connected to
and "Source Index" tells you where it is connected. You then need to do the
same for the upstream device, and so forth. For example, you may find that
INTA is connected to INTC upstream, and INTC is connected to INTB even
further upstream. Once you find that the "Source" field is 0, the "Source
Index" is the GSI number that you are looking for.

CT> For GSI number, I assume it is the irq number I am looking for. But I still
CT> have some questions. First, is it always fixed for each pin of each
CT> IO-APIC? For example, first pin of first IO-APIC has GSI 0, second pin has
CT> 1, ...,  and the first pin of second IO-APIC has GSI 24, second pin has 25,
CT> ...? If so, then irq number will range from 0 to 47 on a two-io-apic
CT> machine. But Linux runs on the same machine can report irq 53 for some
CT> device, which is very confusing to me.

The ACPI MADT table lists all the IOAPICs in the system. Each IOAPIC has a
certain number of pins, which you can read out from the IOAPIC itself. The
first IOAPIC serves GSI 0 through X-1, where X is the number of pins. The
second IOAPIC then serves pins X through X + (Y-1), where Y is the number of
pins of the second IOAPIC and so forth.

CT> Second, some document says GSI number can be overridden. When booting
CT> Fiasco.OC, I can see a line like ovr[0] 2->0.  Does that mean GSI 2
CT> eventually become irq 0?  I am not sure when and why a GSI number needs to
CT> be overridden, but  can the overriding happen to the device I am
CT> interested? If so, how should I deal with it in my device driver, i.e.,
CT> should I use the original GSI number as my device's irq or use the one
CT> after overriding?

The legacy IRQs are also connected to the IOAPIC, typically in a 1:1
fashion. This means IRQx is connected to GSIx, except where overrides are
used. This is only relevant if you want to drive a non-PCI legacy device,
such as the PIT, which uses IRQ0, which is typically connected to GSI2.

Cheers,
Udo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20120728/bb1df0e1/attachment-0001.asc>