OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 8:04 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 3 posts ] 
Author Message
 Post subject: Architectural behavior of INIT/SIPI
PostPosted: Tue Mar 21, 2017 4:14 am 
Offline
Member
Member

Joined: Thu May 17, 2007 1:27 pm
Posts: 999
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

_________________
managarm: Microkernel-based OS capable of running a Wayland desktop (Discord: https://discord.gg/7WB6Ur3). My OS-dev projects: [mlibc: Portable C library for managarm, qword, Linux, Sigma, ...] [LAI: AML interpreter] [xbstrap: Build system for OS distributions].


Top
 Profile  
 
 Post subject: Re: Architectural behavior of INIT/SIPI
PostPosted: Tue Mar 21, 2017 5:17 am 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5099
Korona wrote:
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.

Korona wrote:
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.

Korona wrote:
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.

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

Most likely.

Korona wrote:
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.

Korona wrote:
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.

Korona wrote:
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.


Top
 Profile  
 
 Post subject: Re: Architectural behavior of INIT/SIPI
PostPosted: Tue Mar 21, 2017 7:51 am 
Offline
Member
Member
User avatar

Joined: Sun Feb 20, 2011 2:01 pm
Posts: 110
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).


Attachments:
ChaiOS one thread per CPU.png
ChaiOS one thread per CPU.png [ 13.64 KiB | Viewed 1601 times ]
ChaiOS 128 CPUs.png
ChaiOS 128 CPUs.png [ 15.98 KiB | Viewed 1601 times ]

_________________
Whoever said you can't do OS development on Windows?
https://github.com/ChaiSoft/ChaiOS
Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 3 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: SemrushBot [Bot] and 51 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group