2 ms·

Also, on any modern system, you really don't need the second SIPI. The CPU will come up with the first SIPI, and then ignore the second SIPI. So you can just se

Also, on any modern system, you really don't need the second SIPI. The CPU will come up with the first SIPI, and then ignore the second SIPI. So you can just send a pile of INITs and then a pile of SIPIs (or in theory one broadcast SIPI), and expect the CPUs to come up. For the startup code, you shouldn't need to make a function call. A few lines of memory-less stack-less assembly could get the CPU number and then change the stack, assuming you have a global value that gives the base of a preallocated array of stacks.

Dwedit 4y ago
How "modern" are we talking here? Core 2 Duo? Arrandale? Haswell? Skylake?
- mananaysiempre 4y ago
  Per the OSDev Wiki, Pentium Pro and later[1]: > For newer CPUs (P6, Pentium 4) one SIPI is enough, but I'm not sure if older Intel CPUs (Pentium) or CPUs from other manufacturers need a second SIPI or not. When (and if) that became officially sanctioned behaviour is another question. [1] https://wiki.osdev.org/Symmetric_Multiprocessing#Initialisation_of_an_old_SMP_system https://wiki.osdev.org/Symmetric_Multiprocessing#Initialisat...
vardump 4y ago
> A few lines of memory-less stack-less assembly could get the CPU number and then change the stack... Except for that TSC_AUX (MSR that stores CPU id number) is going to be 0 for all of the cores. Unless you know some other way to get CPU number?
- dfox 4y ago
  Core ID in TSC_AUX is essentially an concession to userspace. As an OS and firmware you are supposed to identify CPU cores by means of their LAPIC ID (as read from APIC configurations MSR or from CPUID). Small issue there is that APIC IDs are structured according to HT/NUMA topology and thus not necessarily consecutive. On the other hand, as an OS on PC-like platform you know how many cores there are supposed to be and what are their APIC IDs before-hand because they were already enumerated by firmware (which is the reason why you can do the one by one AP startup sequence in the first place).
  - JoshTriplett 4y ago
    Exactly: either read the APIC ID and use that to look up the CPU number in a table you already have, or arrange a location in memory to use xadd to assign a sequential CPU number, whichever your OS prefers.

Dwedit 4y ago

How "modern" are we talking here? Core 2 Duo? Arrandale? Haswell? Skylake?

mananaysiempre 4y ago
Per the OSDev Wiki, Pentium Pro and later[1]: > For newer CPUs (P6, Pentium 4) one SIPI is enough, but I'm not sure if older Intel CPUs (Pentium) or CPUs from other manufacturers need a second SIPI or not. When (and if) that became officially sanctioned behaviour is another question. [1] https://wiki.osdev.org/Symmetric_Multiprocessing#Initialisation_of_an_old_SMP_system https://wiki.osdev.org/Symmetric_Multiprocessing#Initialisat...

vardump 4y ago

> A few lines of memory-less stack-less assembly could get the CPU number and then change the stack... Except for that TSC_AUX (MSR that stores CPU id number) is going to be 0 for all of the cores. Unless you know some other way to get CPU number?

dfox 4y ago
Core ID in TSC_AUX is essentially an concession to userspace. As an OS and firmware you are supposed to identify CPU cores by means of their LAPIC ID (as read from APIC configurations MSR or from CPUID). Small issue there is that APIC IDs are structured according to HT/NUMA topology and thus not necessarily consecutive. On the other hand, as an OS on PC-like platform you know how many cores there are supposed to be and what are their APIC IDs before-hand because they were already enumerated by firmware (which is the reason why you can do the one by one AP startup sequence in the first place).
- JoshTriplett 4y ago
  Exactly: either read the APIC ID and use that to look up the CPU number in a table you already have, or arrange a location in memory to use xadd to assign a sequential CPU number, whichever your OS prefers.