Architectural behavior of INIT/SIPI

[Korona]

Hi,

while I have no trouble getting AP startup to work (on the somewhat modern PCs that I have available) I don't quite understand the architectural behavior of the INIT-SIPI-SIPI sequence. The MP Specification states that APs should be started (by the OS) via INIT-SIPI-SIPI. Brendan pointed out in earlier posts that some processors do not need a second SIPI so there is some room for optimization here.

As far as I understand the architectural behavior of INIT is resetting the processor (which includes resetting CS:IP to 0xFFFFFFF0) and executing the BIOS ROM code at this address. Is this correct?

After performing basic initialization the BIOS observes that the processor is an AP and enters a special wait-for-SIPI state (the way that is done does not seem to be architecturally defined?). The architectural behavior of SIPI is leaving the wait-for-SIPI state and setting IP to the page that is determined by the SIPI vector. Again: Is this understanding correct? If it is: Why do processors need two SIPIs at all? Is the second SIPI redundant and only necessary in case of a delivery failure? Are there processors that only exit wait-for-SIPI after two (correctly delivered) SIPIs?

Furthermore the MP Specification states that the OS should program the warm-reset vector and the CMOS shutdown code. It is not clear to me how this interacts with SIPIs and the BIOS boot code. At least on my machines a warm-reset is not necessary to bring up the APs. My hypothesis is that this startup via warm-reset is only meaningful on systems with a 82489DX APIC (as those systems do not support SIPIs) though that is not stated in the MP Specification. Are there non-82489DX systems that need the warm-reset? Does the BIOS enter wait-for-SIPI if the shutdown code is set to warm-reset? If so, is the SIPI vector ignored?

Thanks,
Alexander

[Octocontrabass]

As far as I understand the architectural behavior of INIT is resetting the processor (which includes resetting CS:IP to 0xFFFFFFF0) and executing the BIOS ROM code at this address. Is this correct?

No. That's the behavior of INIT on systems using the 82489DX APIC, which will be 486 and early (<75MHz) Pentiums only. On everything newer than that, INIT halts the CPU and enters the wait-for-SIPI state.

The architectural behavior of SIPI is leaving the wait-for-SIPI state and setting IP to the page that is determined by the SIPI vector. Again: Is this understanding correct?

IP is always 0, it sets CS according to the SIPI. Other than that, you're correct.

Why do processors need two SIPIs at all?

Because Intel says so. I don't think they've ever given a specific reason for it.

Is the second SIPI redundant and only necessary in case of a delivery failure?

Most likely.

Are there processors that only exit wait-for-SIPI after two (correctly delivered) SIPIs?

I don't know if anyone has ever specifically looked for one.

Are there non-82489DX systems that need the warm-reset?

No. The warm reset is only used on systems with the 82489DX, since those systems don't support SIPI.

Does the BIOS enter wait-for-SIPI if the shutdown code is set to warm-reset?

No. CPUs with integrated APICs enter wait-for-SIPI immediately upon receiving an INIT IPI, and the BIOS isn't involved at all. CPUs using the 82489DX reset upon receiving an INIT IPI and begin executing BIOS code, which checks the shutdown code and jumps to the warm reset vector.

[bellezzasolo]

The MP Spec is there for backwards compatibility back to the 486. Modern processors respond differently, but the old ones don't support SIPI.
I saw a good recommendation on here, which was to issue an INIT, then one SIPI. http://wiki.osdev.org/SMP
The warm reset vector is there for the CPUs that don't support SIPI.
If the CPU doesn't start, send another SIPI (it's easier than the accurate timing Intel specifies). This trick seemed to work for me, however my AP startup code left a lot to be desired. Then, at some point you will want to optimise this algorithm based on topology, offloading AP startup to other APs (not necessary right now, but the future might involve hundred of cores. A few milliseconds for each will then add up).