Andrew Fish [mailto:af...@apple.com]  wrote:



On Aug 1, 2014, at 2:48 PM, Jordan Justen <jljus...@gmail.com 
<mailto:jljus...@gmail.com> > wrote:





On Fri, Aug 1, 2014 at 8:12 AM, Scott Duplichan <sc...@notabs.org 
<mailto:sc...@notabs.org> > wrote:



Chen Fan [mailto:chen.fan.f...@cn.fujitsu.com] wrote:


With this patch set, the APs are launched even when
a project never uses mpservice. To minimize boot time
it would be good if no AP launch code runs unless
mpservice is actually used.


I think most need need to start the APs regardless. For example,
nearly all systems should program the MTRRs the same for all APs.

 

You also have to setup SMM on the APs, and the APs have to be in a "well known 
state" when the OS is booted.  This state is defined
in the MP Spec 1.4 (might have moved to ACPI, since MP spec last update was 
1997). 

 

Thanks,

 

Andrew Fish

 

 

AMD reference code does all the AP init needed for OS use. I don't know if the 
same is true for Intel.

I know IBV code bases launch APs for SMM setup as you mention, and also for 
gathering info for

use in SMBIOS tables. On the other hand, is there any disadvantage to making AP 
launch part

of MpService? This is how IBVs do it, as I recall.

 

I know of two cases where launching APs outside of MpService is undesirable. 
One is the standard

EDK2 Duet. When Duet starts, any AP setup beyond that done by the reference 
code has already

been handled by the existing BIOS. The second case is when Duet is used as a 
coreboot payload.

Any needed AP launch will have already been done by coreboot.

Thanks,

Scott

 





If a system has a way to know that there are no APs, then some time
could be saved.

-Jordan

 

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Reply via email to