OSDev.org

Normally, when booting an AP core, it will boot to real mode BIOS, and then the OS will setup protected mode or long mode. But since UEFI is supposed to get rid of real mode, and hand over control in protected mode, doesn't UEFI define a better way to boot AP cores than through the legacy BIOS interface?

There exists a protocol called EFI_MP_SERVICES_PROTOCOL. I'm not sure if this is what you need as I didn't look closely at it.

Maybe it is. On some PCs, it works fine to boot APs with BIOS even if the system was EFI-booted, but on at least one, the AP core faults as soon as the sti instruction is executed.

Not sure how this protocol goes with ExitBootServices. I suppose that before the BSP does exit boot-services, the AP cores must already have gone to the boot-loader stub and sleep there.

Just because the APs start in real mode doesn't mean they have to use the BIOS. Linux, for example, just starts them with a real mode trampoline that switches immediately to protected/long mode, initializes its per-core stuff, and goes into the scheduler. No BIOS at all.

Hi,



I'm not sure if this actually exists in a meaningful way.

I remember (a few years a go) seeing a proposal to add an AP CPU management service to UEFI (from memory, mostly so that portable UEFI applications can use multiple CPUs); but I haven't seen it in any version of the official UEFI specification, and don't know if it was ever actually implemented on any computer.


Cheers,

Brendan

That's not true. The AP will boot to the real-mode reset vector just like the BSP, and so control will always pass first to BIOS. So an AP cannot boot at all without a BIOS ROM. No OS can circumvent this, unless it also provides a boot ROM at the proper location. Linux certainly isn't an exception to that. It's a hack in the BIOS that allows the OS to hook the boot process for the AP and then switch to protected/long mode.

Which means that CPU vendors cannot skip real mode anytime soon, as all commercial OSes relies on real mode for bootstrapping AP cores. That kind of goes against the claims that real mode or protected mode could be removed easily because UEFI passes control in long mode. Before we are even close to such a scenario, major OSes must use UEFI functions to boot APs, and these must be widely supported by UEFI implementations.

Yes it is. Check the MultiProcessor Specification section B.4.2.

No, and the MP specification is obsolete nowadays. It's been replaced with ACPI. In fact, the MP specification never was any good to begin with, which I suspect is the reason why it was never widely adopted and ACPI replaced it.

Also, the specification highlights what I wrote before: Booting AP cores relies on an ancient "hack" in the BIOS that makes it skip the full boot and passes control to an entry-point in REAL MODE.

Did you read section B.4.2? It describes the use of the STARTUP IPI to select the entry point, and the entry point can be set to RAM, meaning no BIOS code will be executed.

You first send it an init, which will end up at the BIOS reset vector. The second message is the startup IPI that needs trampoline code in real mode.

The problem for no longer needing real mode is that even the startup IPI that Intel and AMD defined will take the AP core to real mode, and not to protected mode or long mode.

For the case I have with malfunctioning AP cores under UEFI but not BIOS boot probably means that the AP init code is different between BIOS booting and UEFI booting. Normally, the BIOS would setup things in the AP core during the init phase, but this appears to depend on boot-mode.

Only if you're looking at a 486 or Socket 4 Pentium. Everything newer will halt and wait for the SIPI. This is explained in section 5.2.


Which operating systems does this affect? If it doesn't affect Windows or Linux, I wouldn't be in a hurry to blame the firmware.

That doesn't make sense. I've tested this on a new 4-core AMD, and since the AP core behaves differently between BIOS and UEFI boot, the firmware must be involved.



Mine, of course.

Also, it is Windows and Linux that defines what works and won't doesn't, so the above is just a circular argument.

Hi,

In my opinion; UFI is supposed to (eventually) make it possible to get rid of BIOS and a whole pile of other legacy baggage (
A20 gate, PIC chips, ISA DMA controller, PIT chip, PS/2 emulation for USB keyboard/mouse, legacy emulation modes in disk controllers and video cards, support for the legacy emulation modes in PCI bridges, etc). All of these things are far more painful than real mode.

For a modern CPU (with billions of transistors), supporting real mode costs about 6 of those billions of transistors (mostly because almost everything is still needed for decoding/executing 16-bit code in protected mode and long mode anyway, and all the major differences like segment loads and IVT/IDT are buried in micro-code).

Removing real mode would mean implementing a different way to start AP CPUs in silicon. Starting AP CPUs in protected mode would be a relatively pointless change given that modern systems use long mode and not protected mode (you'd literally be replacing a dependence on a deprecated CPU mode with a dependence on a different deprecated CPU mode). Starting AP CPUs in long mode is complex (because long mode requires paging, and not just a "starting CS:RIP"), and could easily cost more transistors than real mode does.

None of this has anything to do with the firmware. For example, if hardware manufacturers all agreed to never provide BIOS ever again starting from tomorrow, then they could do that (without removing real mode); and the number of people that notice (or care) would probably be completely insignificant.

Note that if CPU manufacturers did implement an alternative way to start AP CPUs (e.g. an "Extended Startup IPI"), then OSs could use that directly instead of using a firmware function (that would have to use the same thing); so even in this case there's no point bothering with a UEFI service for an OS to use to start AP CPUs. However, there would still be some sense in providing a way for (e.g.) "portable EFI byte code applications" to use multi-CPU in a portable way (e.g. some kind of "start all AP CPUs and make them all execute this function in parallel, then shut them all down when the function returns" service).

For the current method of AP CPU startup (which has remained mostly unchanged since the MP specification); the INIT IPI does not cause the CPU to go to the firmware's reset vector. It does an internal "soft reset" of the CPU and puts it into a "wait for SIPI" state.

For cases where rdos has malfunctioning AP CPUs under UEFI, it's impossible for there to be any difference in the firmware code that's executed in response to INIT IPI or Startup IPI, simply because there is none. In theory, at power on the firmware does initialise some things that are not reset by the INIT IPI (e.g. MTRRs), so it is possible that AP CPUs are initialised (at power on) differently under UEFI. However, given that most current firmware is "hybrid" (supporting both BIOS and UEFI) and that the same power on code is used for both cases, this is very unlikely. Far more likely (not forgetting that other OSs don't seem to have a problem at all) is that rdos is buggy - e.g. maybe it relies on assumptions that aren't guaranteed to be true in various cases (especially for UEFI) and fails when the assumptions are false.


Cheers,

Brendan

Yes, but it's because of something the firmware does before it passes control to your OS, not after. When you send the INIT and SIPI, the AP is running entirely under your control - but it was still initialized by the firmware.


Then perhaps it's time to look at Linux and see what it's doing differently.