OSDev.org

Hi all,

In APIC chapter in Intel manuals it is mentioned that "Locally connected I/O devices are connected directly to the processor's local interrupt pint (LINT0 and LINT1). The I/O devices may also be connected to an 8259-type interrupt controller that is in turn connected to the processor through one of the local interrupt pins." .

I am trying to figure out which device/peripherals are connected to LINT0 or LINT1 as I can't find anything documented.

If someone knows anything about that, please share it.

Thanks in advance.

In general, one pin is used for chaining the legacy PIC and the other for NMIs (Or occasionally SMIs). No devices are actually connected to the LINT pins for a couple of reasons, one of which is that id just doesn't work on multiprocessor systems (They inevitably get delivered to one core).

In practice, all devices are connected to the I/O APIC and/or PIC.

Owen wrote:In general, one pin is used for chaining the legacy PIC and the other for NMIs (Or occasionally SMIs). No devices are actually connected to the LINT pins for a couple of reasons, one of which is that id just doesn't work on multiprocessor systems (They inevitably get delivered to one core).

In practice, all devices are connected to the I/O APIC and/or PIC.

Thanks for the quick reply. I am still a bit confused on how this works. It is not mentioned anywhere that LINT0 is connected with PIC.

Thanks.

Its possible that either LINT0 or 1 is, or none at all (For example, often APs won't be connected to the PIC; only the BSP needs a connection).

Owen wrote:Its possible that either LINT0 or 1 is, or none at all (For example, often APs won't be connected to the PIC; only the BSP needs a connection).

Ok, so from what you're saying I am concluding that it is the job of the OS to find out at which LINT pin (O or 1) PIC is connected to, is that right? I am supprised that the don't have documented that...

Another question is this: Is it possible to forward an interrupt generated by PIC as SMI to the processor. AFAIU, it should be possible if we assume that PIC is connected to LINT0 and LINT0's delvery mode has been set-up to SMI..

Thanks a lot.

Hi,

limp wrote:Ok, so from what you're saying I am concluding that it is the job of the OS to find out at which LINT pin (O or 1) PIC is connected to, is that right? I am supprised that the don't have documented that...

You need to read Intel's Multiprocessor Specification; not just for the tables, etc but also for the wiring diagrams that show how an 80x86 CPU is connected in "PC Compatible" hardware.

limp wrote:Another question is this: Is it possible to forward an interrupt generated by PIC as SMI to the processor. AFAIU, it should be possible if we assume that PIC is connected to LINT0 and LINT0's delvery mode has been set-up to SMI..

Any IRQ connected to the I/O APIC can be configured to send an SMI (you don't need to attempt to misconfigure the local APIC to do it). However, it's entirely pointless - there's nothing you can gain by getting the CPU to execute the firmware's SMM hander (and no way to change the firmware's SMM handler; and no way to avoid trashing the computer if you could replace the firmware's SMM handler).


Cheers,

Brendan

Hi Brendan!

Brendan wrote: You need to read Intel's Multiprocessor Specification; not just for the tables, etc but also for the wiring diagrams that show how an 80x86 CPU is connected in "PC Compatible" hardware

Thanks for pointing this to me. I can't really find a good reason on why this information is not included somewhere in the standard Intel manuals or in the southbridge one. In my case, the target is not a multiprocessor one but the LAPIC and I/O APIC are in use. One of the requirements of the presented configurations/wirirng diagrams in Intel's Multiprocessor Specification is that the system supports two (or more I guess) processors. What applies to my UP case?

Brendan wrote: Any IRQ connected to the I/O APIC can be configured to send an SMI (you don't need to attempt to misconfigure the local APIC to do it).

That seems not to be the case at least with ICH7. Please have a look at the following quote:

From ICH7 datasheet:

The local APIC (in the processor) has a delivery mode option to interpret Front Side Bus messages as a SMI in which case the processor treats the incoming interrupt as a SMI instead of as an interrupt. This does not mean that the ICH7 has any way to have a SMI source from ICH7 power management logic cause the I/O APIC to send an SMI message (there is no way to do this). The ICH7’s I/O APIC can only send interrupts due to interrupts which do not include SMI, NMI or INIT. This means that in IA32/IA64 based platforms, Front Side Bus interrupt message format delivery modes 010 (SMI/PMI), 100 (NMI), and 101 (INIT) as indicated in this section, must not be used and is not supported. Only the hardware pin connection is supported by ICH7.

However, if you take a look at the delivery modes mentioned in the "Interrupt Message Address Format" table, you can see that you can choose an SMI/PMI delivery mode by setting the delivery mode to 010 and it's not mentioned anywhere in the table that you can't use this mode, or that it is reserved!

Regards

It is possible in that case that the SMI is connected to one of the LINT pins and the processor has no NMI. Its really quite irrelevant; you should configure the processor as specified by the ACPI MADT or the MP tables.

It's being a while since I first did this post but until recently I didn't have that chance to have a progress update...

Owen wrote:It is possible in that case that the SMI is connected to one of the LINT pins and the processor has no NMI. Its really quite irrelevant; you should configure the processor as specified by the ACPI MADT or the MP tables.

I parsed the MP tables and I found that LINT0 is of ExtINT type and it is connected to PIC and that LINT1 is of NMI type as expected.

I also found that the "Source Bus IRQ" is 0 for both LINT0 and LINT1 meaning that the first interrupt signal from the source bus is connected to these pins.

Finally, the "Source Bus ID" for both LINT pins is 0x5. This ID identifies the bus from which the interrupt signal came. However, I can't find out which bus has an ID of 0x5. Can anyone help me on that? Also, it doesn't make much sense to me to have the same BUS connected on both LINT pins (both pins have same Source Bus ID and Source Bus IRQ values).

Thanks again for the help.

limp wrote:It's being a while since I first did this post but until recently I didn't have that chance to have a progress update...

Owen wrote:It is possible in that case that the SMI is connected to one of the LINT pins and the processor has no NMI. Its really quite irrelevant; you should configure the processor as specified by the ACPI MADT or the MP tables.

I parsed the MP tables and I found that LINT0 is of ExtINT type and it is connected to PIC and that LINT1 is of NMI type as expected.

I also found that the "Source Bus IRQ" is 0 for both LINT0 and LINT1 meaning that the first interrupt signal from the source bus is connected to these pins.

Finally, the "Source Bus ID" for both LINT pins is 0x5. This ID identifies the bus from which the interrupt signal came. However, I can't find out which bus has an ID of 0x5. Can anyone help me on that? Also, it doesn't make much sense to me to have the same BUS connected on both LINT pins (both pins have same Source Bus ID and Source Bus IRQ values).

Thanks again for the help.

Are you sure those fields are even valid in combination with types ExtInt and NMI? I would expect them to be undefined in this case (The sources are already defined)