APIC? What is this?

ThatWasFat

Member
Dec 15, 2001
93
0
0
Well, I have seen it for years, but I have never know what it was. On some sites it says its a Multiprocessor interrupt protocol, but, then the kernel configuration documentation (linux..) said that some single CPU systems have it. Can someone enlighten me?:confused:
 

Wolfsraider

Diamond Member
Jan 27, 2002
8,305
0
76
advanced programing interrupt controller(bus)
APIC
Advanced Programmable Interrupt Controller. Either a local APIC or an I/O APIC. It is attached to the APIC bus.


APIC bus
A special non-architechural bus on which the APICs in the system send messages.


I/O APIC
A special APIC for receiving and distributing interrupts from external devices which is backward compatible with the PIC. There is generally only one per computer


an APIC built in to the processor. It is responsible for dispatching interrupts sent over the APIC bus to its processor core and sending interrupts to other processors over the APIC bus.
MP systems have a special bus to which all APICs in the system are connected. This bus is one of the ways the processors can communicate with one another (the other, of course, is shared memory). APICs (both local and I/O) are memory mapped devices. The default location for the local APIC is at 0xfee00000 in physical memory. The local APIC will appear in the same place for each processor, but each processor will reference its own APIC; the APIC intercepts memory references to its registers, and those references will not generate bus cycles on some systems. Since APICs are mapped in high memory, the APs will have to switch to protected mode before they can intialise their local APICs. If you like, you can map the APIC to a different address using the paging unit, but be sure to disable caching in the page table entry since some registers can change between accesses. For this reason, pointers to APIC registers should be volatile. To initialise the BSP's local APIC, set the enable bit in the spurious interrupt vector register and set the error interrupt vector in the local vector table

Booting Application Processors
Once you have detected the processors in the system, set up your local APIC, and verified that you can communicate with it (hint: read the APIC version register), it's time to boot the APs. N.B. that it is good practise to not try to boot the BSP here. That would be bad.
Since the APs will wake up in real mode, everything they need to get started should be in low memory (below 0x100000 or one megabyte). First, set the shutdown code by setting address 0:f to 0xa. Then, grab a page of memory for the AP's stack. You will also need space to store the `trampoline' code, i.e. the code the processor executes after waking up to switch to protected mode and jump to the kernel. You can either use the same page of code for each processor or store the code at the bottom of the processor's stack. Note that the start of the code must be at a page-aligned address. Copy the code there, then set the warm reset vector at address 40:67 to the start of this code. Next, you should reset a bit in the kernel which the processor will use to signal that it has booted and finished initialisation and clear any APIC error by writing a zero to the error status register. If you need to pass any parameters or data to the AP, now would be a good time to set that up. For example, since OpenBLT's kernel runs in high memory, I have to pass the address of the page directory in memory so that the AP can load it and enable paging before calling the kernel.

Now you can actually boot the processor. The procedure consists of sending a sequence of interrupts to the processor. The incremental effect of each is undefined, but at the end of the sequence, the processor will be booted. First send an INIT IPI. Assert the INIT signal by writing the target processor's APIC ID to the high word of the interrupt command register. Then write to the low word with the bits set to enable the INIT delivery mode, level triggered, and assert the interrupt. Deassert INIT by repeating the procedure with the assert bit reset. Now, wait 10 ms. Use of the APIC timer is suggested.

If the local APIC is not an 82489dx, you need to send two STARTUP IPIs. Clear APIC errors, set the target APIC ID in the ICR, then send the interrupt by writing to the low word of the ICR with bits set for STARTUP delivery mode and with the code vector in the low byte. The code vector is the physical page number at which the processor should start executing, i.e. the start of your trampoline code. Wait 200 ms, then check the low word of the ICR to make sure bit 16 is reset to indicate the interrupt was dispatched before sending the second STARTUP. After sending it, spin and wait for the AP to set its ready bit in memory. You may want to set a timeout of 5 seconds, after which you assume the processor did not wake up

hopefully there is enough info for you to see the answer you wanted

hope this helps

 

ThatWasFat

Member
Dec 15, 2001
93
0
0
Sweet jesus almighty. I THINK I might have gotten something out of it.

Let me recap what I think I learned.

There is an APIC bus, which the I/O APIC is connected to. This replaces the PIC (or somewhere I read there were multiple PICs). This just handles the interrupts from devices. It's (I hope) seemingly as simple as that.

The APIC built into the processor handles interrupts once they get to the CPU.

So, the I/O APIC handles IRQs and sends the interrupts to the APIC Bus, which sends the interrupts to the APIC in the processor, which then sends the interrupt.

AM I right? Or close? OR just dumb. Cause that was WAY too much info ;)