Hello,
I as wondering why, at least according to Intel manuals (volume 3, chapter 7.5.4.1 -> 15), two SIPIs are needed to boot a pentium class application processor. Not only does my HT machine already boot after the first SIPI message, but also all code I just had a look at seems to ignore the second STARTUP IPI: Xen, bochs, linux
The linux code seems especially weired to me as, it sends an INIT de-assert in between the regular INIT and the SIPI..
regrads,
gaf
INIt-SIPI-SIPI
Re:INIt-SIPI-SIPI
Hi,
For 80486 (with an external 8249DX local APIC), you must use an INIT IPI followed by an "INIT level de-assert" IPI without any SIPI's. This means you can't tell them where to start executing (the vector part of a SIPI) and they always start executing BIOS code. In this case you set the BIOS's CMOS reset value to "warm start with far jump" (i.e. set CMOS location 0x0F to the value 10) so that the BIOS will do a "jmp far [0:0x0469]", and then put the segment & offset of your AP entry point at 0x0469.
The "INIT level de-assert" IPI isn't supported on newer CPUs (Pentium 4 and Intel Xeon), and AFAIK it is ignored completely on these CPUs.
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. It's also possible that the second SIPI is there in case there's a delivery failure for the first SIPI (bus noise, etc).
I normally send the first SIPI and then wait to see if the AP CPU increases a "number of started CPUs" counter. If it doesn't increase this counter within a few milli-seconds, then I send the second SIPI. This is different to Intel's generic algorithm (which has a 200 micro-second delay between SIPIs), but trying to find a time source capable of accurately measuring a 200 micro-second delay during early boot isn't so easy. I've also found that on real hardware, if the delay between SIPIs is too long (and you don't use my method) an AP CPU can run the OS's early AP startup code twice (which in my case would lead to the OS thinking there's twice as many AP CPUs as there are).
Cheers,
Brendan
The startup sequence is different for different CPUs. Intel's system programmer's manual (section 7.5.4) contains the initialization protocol for Intel Xeon processors, and doesn't cover older CPUs. For the generic "all CPU types" algorithm, see Intel's Multi-processor Specification.gaf wrote:I as wondering why, at least according to Intel manuals (volume 3, chapter 7.5.4.1 -> 15), two SIPIs are needed to boot a pentium class application processor. Not only does my HT machine already boot after the first SIPI message, but also all code I just had a look at seems to ignore the second STARTUP IPI: Xen, bochs, linux
The linux code seems especially weired to me as, it sends an INIT de-assert in between the regular INIT and the SIPI..
For 80486 (with an external 8249DX local APIC), you must use an INIT IPI followed by an "INIT level de-assert" IPI without any SIPI's. This means you can't tell them where to start executing (the vector part of a SIPI) and they always start executing BIOS code. In this case you set the BIOS's CMOS reset value to "warm start with far jump" (i.e. set CMOS location 0x0F to the value 10) so that the BIOS will do a "jmp far [0:0x0469]", and then put the segment & offset of your AP entry point at 0x0469.
The "INIT level de-assert" IPI isn't supported on newer CPUs (Pentium 4 and Intel Xeon), and AFAIK it is ignored completely on these CPUs.
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. It's also possible that the second SIPI is there in case there's a delivery failure for the first SIPI (bus noise, etc).
I normally send the first SIPI and then wait to see if the AP CPU increases a "number of started CPUs" counter. If it doesn't increase this counter within a few milli-seconds, then I send the second SIPI. This is different to Intel's generic algorithm (which has a 200 micro-second delay between SIPIs), but trying to find a time source capable of accurately measuring a 200 micro-second delay during early boot isn't so easy. I've also found that on real hardware, if the delay between SIPIs is too long (and you don't use my method) an AP CPU can run the OS's early AP startup code twice (which in my case would lead to the OS thinking there's twice as many AP CPUs as there are).
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:INIt-SIPI-SIPI
seemed a nice stuff to start http://www.osdev.org/osfaq2/index.php/MultiProcessors
Re:INIt-SIPI-SIPI
Hello Brendan,
thanks for clearing that up..
My method right now is by the way to send all three IPIs at once only waiting for the delivering flag to get cleaned in between. Then I wait until either the processor responds by setting a flag in some variable, or until a my local apic timer runs-off signaling a time-out.
regards,
gaf
thanks for clearing that up..
I see - that should explain the linux source. As I'm not planning to support external APCIs, I of course didn't look up the details of their initialization and thus was a bit surpised when I saw the second INIT.Brendan wrote:For 80486 (with an external 8249DX local APIC), you must use an INIT IPI followed by an "INIT level de-assert" IPI without any SIPI's.
Maybe I'm wrong, but doesn't that mean that the second SIPI is actually needed to finish the processor initialization ? After all the multiprocessor specification states in B 4.2 that a SIPI (pair?) "can be issued only one time after RESET or after an INIT IPI reception or pin assertion". If the first SIPI was already enough to start the processor any subsequent SIPIs should in my opinion be ignored..Brendan wrote:I've also found that on real hardware, if the delay between SIPIs is too long (and you don't use my method) an AP CPU can run the OS's early AP startup code twice (which in my case would lead to the OS thinking there's twice as many AP CPUs as there are).
My method right now is by the way to send all three IPIs at once only waiting for the delivering flag to get cleaned in between. Then I wait until either the processor responds by setting a flag in some variable, or until a my local apic timer runs-off signaling a time-out.
regards,
gaf