diff options
author | Aaron Durbin <adurbin@chromium.org> | 2013-02-13 11:22:25 -0600 |
---|---|---|
committer | Ronald G. Minnich <rminnich@gmail.com> | 2013-03-21 22:56:21 +0100 |
commit | 738af675d1b29847112f32b3fb2ac2524bb7c4ca (patch) | |
tree | 4c2f0b4bd10151b4bc717dc9c43e205b93960cd5 /src/southbridge/intel/esb6300 | |
parent | 159f2ef03a59607c58c0474f9b2941b03710b498 (diff) | |
download | coreboot-738af675d1b29847112f32b3fb2ac2524bb7c4ca.tar.xz |
haswell: support for parallel SMM relocation
The haswell processors support the ability to save their SMM state
into MSR space instead of the memory. This feaure allows for parallel
SMM relocation handlers as well as setting the same SMBASE for each
CPU since the save state memory area is not used.
The catch is that in order determine if this feature is available the
CPU needs to be in SMM context. In order to implement parallel SMM
relocation the BSP enters the relocation handler twice. The first time
is to determine if that feature is available. If it is, then that
feature is enabled the BSP exits the relocation handler without
relocating SMBASE. It then releases the APs to run the SMM relocation
handler. After the APs have completed the relocation the BSP will
re-enter the SMM relocation handler to relocate its own SMBASE to the
final location. If the parallel SMM feature is not available the BSP
relocates its SMBASE as it did before.
This change also introduces the BSP waiting for the APs to relocate
their SMBASE before proceeding with the remainder of the boot process.
Ensured both the parallel path and the serial path still continue
to work on cold, warm, and S3 resume paths.
Change-Id: Iea24fd8f9561f1b194393cdb77c79adb48039ea2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2801
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Diffstat (limited to 'src/southbridge/intel/esb6300')
0 files changed, 0 insertions, 0 deletions