OSDev.org

Hi,

I've read that only the primary processor was powered on by the ROM BIOS when the PC boots up, but now my OS is functionnal, I'd like to know how I can actually turn on these processors and tell them what to do, allowing me to do real multitasking on systems with multiple cores/processors.

Is there an I/O port to send bytes to, some register to setup, and which ones in this case ?
And is it processor-specific or is there a standard interface ?

I suggest you read the section "Multiple-Processor Management" in the Intel manuals. In my (albeit old) version its 3A chapter 8.

Regards,
John.

Hi,

AbstractYouShudNow wrote:And is it processor-specific or is there a standard interface ?

The full thing goes a bit like this:

• Search for the ACPI RSDP and check it's sane
• If sane RSDP found, use it to find the ACPI RSDT table and/or ACPI XSDT table and check if it's sane
• If sane RSDT and/or XSDT found, use it to find the ACPI MADT/APIC table and check if it's sane
• If sane MADT/APIC table is found, parse it to determine local APIC address and build a list of APIC IDs for present CPUs
• Else if no sane MADT/APIC table is found (for any reason above) search for MultiProcessor Specification Table, check it's sane and parse it to determine local APIC address and build a list of APIC IDs for present CPUs
• If any extra CPUs were found:
  • Install/setup a "trampoline", which is where the extra CPUs will start executing. The extra CPUs will start in real mode, and typically this trampoline will want to do something to tell other CPUs that the extra CPU has started and setup segments, stack, etc (possibly including switching to protected mode or long mode or something) before jumping to somewhere inside the normal kernel.
  • Make sure you've got some sort of timer setup/working (you'll need it for the next part).
  • For each extra CPU:
    • Prepare to start the CPU. This can include allocating memory that it can use for stack space, and setting various pieces of data (e.g. value to load into ESP, value to load into CR3, values for "lgdt" and "lidt", etc) in the trampoline.
    • Send the "INIT-SIPI-SIPI" sequence to make the extra CPU start executing the trampoline's code; and wait until the CPU does "something" to tell you it has started. This needs to have both time delays (in the "Init-SIPI-SIPI" sequence) and time-out/s (e.g. if the extra CPU doesn't do "something" to tell you it has started within a certain amount of time, then assume the CPU failed and tell the user).

Notes:

• If you only support modern systems, you can skip the "MultiProcessor Specification Table" part.
• If you do support very old systems (e.g. 80486) then there's a different "INIT-INIT-SIPI" sequence you need to use on these very old systems.

For all of the above, you'd want to read:

• Intel's "MultiProcessor Specification". Even if you only support modern systems and don't plan to parse the "MultiProcessor Specification Table", this specification includes a lot of useful information; including a description of the "INIT-SIPI-SIPI" sequence, the "INIT-INIT-SIPI" sequence, and background knowledge you'd need to handle things like IRQs/IO APICs, etc.
• The ACPI specification. This is a huge specification and most of it is irrelevant for starting extra CPUs - you'd only need to read the parts you need (RSDP, RSDT/XSDT and MADT/APIC) and can skip everything else (for now).
• The chapter on local APICs in Intel's System Programming Guide. You need to understand how to use the local APIC/s to send IPIs ("Inter-Processor Interrupts") to other CPUs.

Cheers,

Brendan

Another thing:

• If the system has ACPI tables, ignore everything in the MP tables. The probability is that they lie.

Brendan wrote:The extra CPUs will start in real mode

I am just wondering whether or not this will be a problem in the future. Uniprocessor systems with UEFI can basically live without touching the real mode anyhow. It could be possible to remove that feature from the CPU architecture.

However, now we are kind of stuck with it again. Of course there could be an improved "INIT-SIPI-SIPI" sequence that does not expect the CPU to start in real mode.

Hi,

Antti wrote:

Brendan wrote:The extra CPUs will start in real mode

I am just wondering whether or not this will be a problem in the future. Uniprocessor systems with UEFI can basically live without touching the real mode anyhow. It could be possible to remove that feature from the CPU architecture.

However, now we are kind of stuck with it again. Of course there could be an improved "INIT-SIPI-SIPI" sequence that does not expect the CPU to start in real mode.

If Intel/AMD wanted to make the CPU start in "16-bit protected mode with no GDT or IDT (with things like NMI disabled until after the first IRET is executed) and a dodgy value in CS" it wouldn't be too hard. It'd also be relatively easy for OS developers to write a trampoline that works for both real mode and 16-bit protected mode (e.g. begin with "lgdt [cs:GDTR]" and then set the flag in CR0 to enable protected mode even when it's already enabled).

I'd assume that (for technical reasons involving the size/format of messages sent/received by APICs) all IPIs are limited to a maximum of 8 bits of data (either an 8-bit interrupt vector for normal IPIs, or an 8-bit "starting address" for SIPI); so I can't imagine a "mega-SIPI" that carries enough information to avoid the need for a trampoline.

I'd also point out that there is a "Multiprocessor Services Protocol" for UEFI (that provides functions to start/stop CPUs); however it's part of the "Platform Initialization Specification" and not part of the normal UEFI standard. I wouldn't be too surprised if sooner or later this protocol is made available as a run-time service so that OSs and UEFI applications can use it in a portable way.


Cheers,

Brendan