4
\$\begingroup\$

By what mechanism is a BIOS or a kernel able to "see" (enumerate,identify,whatever term is right) other CPUs in an SMP system? How is the boot CPU able to initialise and then "launch" the second or third, fourth CPU?

This is not a question on how a user program has his thread scheduled on another cpu, thread affinity etc, but really down to the nitty-gritty lowest-level mechanism by which this works.

How I vaguely understand this might work is that an MMU temporarily keeps the second CPU on hold until the first one has initialised everything for itself, then for the second CPU, then receives a signal from the main CPU to start the other one. Still then it's not certain what the first thing is that the other cpu executes in an intel system; i.e. would it also start in 8086 mode first, requiring it to run the routine that enables A20 and jumps into PM?

I have coded in ASM in a previous life so I can understand well-explained theoretical answers but I have very little real-life coding experience so just being redirected to Linux kernel source (which I'm already going to try anyway) won't be an answer to my Q :-)

\$\endgroup\$
2
  • 1
    \$\begingroup\$ The bios is usually tailored for the board. the bios for a multi socket board will go look for those processors to see if they are present just like it goes to look at the multiple memory slots to see what is populated. The exact mechanism for detection is likely different between memories and processors. And is definitely processor family specific a specific x86 processor or family might be different from another as a power pc, amd, etc. the bios knows what that board supports and knows how to talk to whatever is allowed to be there. \$\endgroup\$
    – old_timer
    Commented Jan 18, 2012 at 15:07
  • 1
    \$\begingroup\$ Some people have flagged this for superuser but I do not see how discussion of how the bare metal discussion between processors makes more sense there then it would on here or stack overflow. \$\endgroup\$
    – Kortuk
    Commented Jan 19, 2012 at 12:45

2 Answers 2

4
\$\begingroup\$

The simple solution is that physical processors are identified using a wire connection. When you put your CPU into mainboard, there is a lot of pins on it. A pair of them can be simply short-connected inside CPU and used to say "I'm connected".

Additional CPU cores inside a single physical processor can be obtained by executing a special machine code instruction. CPU always know who it is and is ready to tell us when we use the "magic" machine code instruction.

The concrete solution depends on the particular computer system, BIOS, CPU family etc. The BIOS have to know exactly what different possible CPUs can it expect in the mainboard. (It is not possible to put 2-core CPU in an old mainboard which wasn't designed for 2-core CPUs.)

You can find very detailed information about x86/x64 CPUs on www.intel.com.

\$\endgroup\$
2
\$\begingroup\$

On an Intel system, execution always starts on cpu-0 on a predefined address. The other cpus are in a halt state, they do nothing but waiting for an special interrupt. On a single socket, multicore cpu this behavior is hardwired - if you power up such a cpu, only ever cpu-0 will start execution.

The cpu-0 running the BIOS enumerates then the basic hardware (especially information about other cpus) and stores it in the ACPI tables.

Further cores are started via ACPI function. The function issues an IPI (Interprocessor Interrupt) to a halted logical processor, it then begins executing code (the new thread) at an address specified as part of the IPI.

If you really do want to see the gory details, an example is at http://lxr.linux.no/#linux+v3.2/arch/x86/kernel/smpboot.c#L477 .

Further details and documentation is in the Intel® 64 and IA-32 Architectures Software Developer's Manual Volume 3 (System Programming Guide), chapter 8.6. As Intel keeps randomly changing the link, you better find it with google.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.