summaryrefslogtreecommitdiff
path: root/src/include
diff options
context:
space:
mode:
authorRocky Phagura <rphagura@fb.com>2020-07-21 14:48:48 -0700
committerDavid Hendricks <david.hendricks@gmail.com>2020-08-15 02:16:32 +0000
commitafb7a814783cda12f5b72167163b9109ee1d15a7 (patch)
tree191e6a067c12da5fda30bed060fbe5cfe89891e0 /src/include
parent5b52592773fce8ba33a18380074b7dcdba7721b4 (diff)
downloadcoreboot-afb7a814783cda12f5b72167163b9109ee1d15a7.tar.xz
cpu/x86/smm: Introduce SMM module loader version 2
Xeon-SP Skylake Scalable Processor can have 36 CPU threads (18 cores). Current coreboot SMM is unable to handle more than ~32 CPU threads. This patch introduces a version 2 of the SMM module loader which addresses this problem. Having two versions of the SMM module loader prevents any issues to current projects. Future Xeon-SP products will be using this version of the SMM loader. Subsequent patches will enable board specific functionality for Xeon-SP. The reason for moving to version 2 is the state save area begins to encroach upon the SMI handling code when more than 32 CPU threads are in the system. This can cause system hangs, reboots, etc. The second change is related to staggered entry points with simple near jumps. In the current loader, near jumps will not work because the CPU is jumping within the same code segment. In version 2, "far" address jumps are necessary therefore protected mode must be enabled first. The SMM layout and how the CPUs are staggered are documented in the code. By making the modifications above, this allows the smm module loader to expand easily as more CPU threads are added. TEST=build for Tiogapass platform under OCP mainboard. Enable the following in Kconfig. select CPU_INTEL_COMMON_SMM select SOC_INTEL_COMMON_BLOCK_SMM select SMM_TSEG select HAVE_SMI_HANDLER select ACPI_INTEL_HARDWARE_SLEEP_VALUES Debug console will show all 36 cores relocated. Further tested by generating SMI's to port 0xb2 using XDP/ITP HW debugger and ensured all cores entering and exiting SMM properly. In addition, booted to Linux 5.4 kernel and observed no issues during mp init. Change-Id: I00a23a5f2a46110536c344254868390dbb71854c Signed-off-by: Rocky Phagura <rphagura@fb.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/43684 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Diffstat (limited to 'src/include')
-rw-r--r--src/include/cpu/x86/smm.h18
1 files changed, 18 insertions, 0 deletions
diff --git a/src/include/cpu/x86/smm.h b/src/include/cpu/x86/smm.h
index a3101e5155..db63e8be25 100644
--- a/src/include/cpu/x86/smm.h
+++ b/src/include/cpu/x86/smm.h
@@ -128,6 +128,12 @@ static inline bool smm_points_to_smram(const void *ptr, const size_t len)
* into this field so the code doing the loading can manipulate the
* runtime's assumptions. e.g. updating the APIC id to CPU map to
* handle sparse APIC id space.
+ * The following parameters are only used when X86_SMM_LOADER_VERSION2 is enabled.
+ * - smm_entry - entry address of first CPU thread, all others will be tiled
+ * below this address.
+ * - smm_main_entry_offset - default entry offset (e.g 0x8000)
+ * - smram_start - smaram starting address
+ * - smram_end - smram ending address
*/
struct smm_loader_params {
void *stack_top;
@@ -141,12 +147,24 @@ struct smm_loader_params {
void *handler_arg;
struct smm_runtime *runtime;
+
+ /* The following are only used by X86_SMM_LOADER_VERSION2 */
+#if CONFIG(X86_SMM_LOADER_VERSION2)
+ unsigned int smm_entry;
+ unsigned int smm_main_entry_offset;
+ unsigned int smram_start;
+ unsigned int smram_end;
+#endif
};
/* Both of these return 0 on success, < 0 on failure. */
int smm_setup_relocation_handler(struct smm_loader_params *params);
int smm_load_module(void *smram, size_t size, struct smm_loader_params *params);
+#if CONFIG(X86_SMM_LOADER_VERSION2)
+u32 smm_get_cpu_smbase(unsigned int cpu_num);
+#endif
+
/* Backup and restore default SMM region. */
void *backup_default_smm_area(void);
void restore_default_smm_area(void *smm_save_area);