Re: [edk2] UEFI task as MSc work

Subject: Re: [edk2] UEFI task as MSc work

From: Andrew Fish <>

To: Rafael Machado <>

Date: 2014-03-18 18:14:43

On Mar 18, 2014, at 4:32 AM, Rafael Machado <> wrote:

Hi Everyone

Thanks for the answers.
Another point that come during my last meeting with my teacher was (This will be a polemical question):

"If the idea is to have a fast way to boot the system and execute some parallel task, wouldn't it be better create a Linux minimal image ?

In a lot of cases yes. You do run into the issue of having to install the OS. 

Doing the development of the mp services in future someone will create a scheduler, aren't we creating another operating system, prior to the "real" operating system (windows, linux,....) ? "

Well this brings up another key point. EFI is Event Driven, not threaded. So EFI does not have a scheduler on the boot processor.  We picked an event model as it is more deterministic and simpler to program and get right. Determinism is important especially on prototype hardware as you tend to crash in the same place when the hardware is busted. 

While we found this presentation many years after we decide the event model was the way to go, we find it helps to educate those who say EFI is broken since it does not support threads:

My was that UEFI was created to standardize the firmware interfaces, and that it's faster than a minimal Linux, but I didn't have the answer about opening a door to create another kind of "UEFI OS" being executed before the real system OS (windows, linux,....)

An OS, with a scheduler, is really really good at loading and stressing a system. It is often difficult to debug hardware failures when the OS crashes. 

Does anyone here have a good reason for creating the MP services ?

Well the MpService protocol ( exists on a lot of platforms today.  It is hard to use as EFI is only safe to run on the boot processor. Not even DEBUG prints and ASSERTs are MP safe. 

and Why creating it is really needed ?

The value to creating a more robust MP environment in the PI world ( is to enable deterministic diagnostics. For example is a scheduler is running you can not get a cache into a known state. While the OS helps, it can also get in the way of a certain class of tests that require determinism. 

The boot firmware may also run into to a computationally complex, or high memory bandwidth, task that requires it to use MP services. Perhaps there is a very large file that needs to be decompressed (OS install/recovery image), or a robust memory test may be required on certain boots. 

The biggest issue with writing MP PI code is most of the times it is not done correctly. Some non MP safe library function ends up getting called and it is just luck that it works.


Andrew Fish

Thanks everyone for the help.
Rafael R. Machado