coreboot-gerrit April 2022

coreboot-gerrit@coreboot.org

1 participants
5879 discussions

Change in coreboot[master]: mb/emulation/qemu-q35: Support PARALLEL_MP with SMM_ASEG
by build bot (Jenkins) (Code Review) 07 Apr '22

07 Apr '22

Attention is currently required from: Kyösti Mälkki. build bot (Jenkins) has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/61494 ) Change subject: mb/emulation/qemu-q35: Support PARALLEL_MP with SMM_ASEG ...................................................................... Patch Set 7: Verified+1 -- To view, visit https://review.coreboot.org/c/coreboot/+/61494 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I7db55aaabd16a6ef585c4802218790bf04650b13 Gerrit-Change-Number: 61494 Gerrit-PatchSet: 7 Gerrit-Owner: Kyösti Mälkki <kyosti.malkki(a)gmail.com> Gerrit-Reviewer: Angel Pons <th3fanbus(a)gmail.com> Gerrit-Reviewer: Arthur Heymans <arthur(a)aheymans.xyz> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: Paul Menzel <paulepanter(a)mailbox.org> Gerrit-Attention: Kyösti Mälkki <kyosti.malkki(a)gmail.com> Gerrit-Comment-Date: Thu, 07 Apr 2022 22:19:58 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

1 0

Change in coreboot[master]: arch/x86/tables.c: Increase MAX_SMBIOS_SIZE
by build bot (Jenkins) (Code Review) 07 Apr '22

07 Apr '22

build bot (Jenkins) has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/63484 ) Change subject: arch/x86/tables.c: Increase MAX_SMBIOS_SIZE ...................................................................... Patch Set 2: Verified+1 -- To view, visit https://review.coreboot.org/c/coreboot/+/63484 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: Idd47e55d8d679cc70eae996ee1af3ad7eaa1d0cc Gerrit-Change-Number: 63484 Gerrit-PatchSet: 2 Gerrit-Owner: Arthur Heymans <arthur(a)aheymans.xyz> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Comment-Date: Thu, 07 Apr 2022 22:16:04 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

1 0

Change in coreboot[master]: cpu/x86/smm: SMM module loader version 2
by Rocky Phagura (Code Review) 07 Apr '22

07 Apr '22

Rocky Phagura has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/43684 ) Change subject: cpu/x86/smm: SMM module loader version 2 ...................................................................... cpu/x86/smm: SMM module loader version 2 Xeon-SP a 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 specifc 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 is 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(a)fb.com> --- M src/cpu/x86/Kconfig M src/cpu/x86/smm/Makefile.inc A src/cpu/x86/smm/smm_module_loaderv2.c M src/include/cpu/x86/smm.h 4 files changed, 678 insertions(+), 0 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/84/43684/1 diff --git a/src/cpu/x86/Kconfig b/src/cpu/x86/Kconfig index 5394cd0..b3a16bc 100644 --- a/src/cpu/x86/Kconfig +++ b/src/cpu/x86/Kconfig @@ -121,6 +121,14 @@ endif +config X86_SMM_LOADER_VERSION2 + bool + default n + depends on HAVE_SMI_HANDLER + help + This option enables SMM module loader that works with server + platforms which may contain more than 32 CPU threads. + config SMM_LAPIC_REMAP_MITIGATION bool default y if NORTHBRIDGE_INTEL_I945 diff --git a/src/cpu/x86/smm/Makefile.inc b/src/cpu/x86/smm/Makefile.inc index dbe567a..1273a6c 100644 --- a/src/cpu/x86/smm/Makefile.inc +++ b/src/cpu/x86/smm/Makefile.inc @@ -1,6 +1,10 @@ ## SPDX-License-Identifier: GPL-2.0-only +ifeq ($(CONFIG_X86_SMM_LOADER_VERSION2),y) +ramstage-y += smm_module_loaderv2.c +else ramstage-y += smm_module_loader.c +endif ramstage-y += smi_trigger.c ifeq ($(CONFIG_ARCH_RAMSTAGE_X86_32),y) diff --git a/src/cpu/x86/smm/smm_module_loaderv2.c b/src/cpu/x86/smm/smm_module_loaderv2.c new file mode 100644 index 0000000..d1ccec0 --- /dev/null +++ b/src/cpu/x86/smm/smm_module_loaderv2.c @@ -0,0 +1,648 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#include <string.h> +#include <rmodule.h> +#include <cpu/x86/smm.h> +#include <commonlib/helpers.h> +#include <console/console.h> +#include <security/intel/stm/SmmStm.h> +test +#define FXSAVE_SIZE 512 +#define SMM_CODE_SEGMENT_SIZE 0x10000 +/* FXSAVE area during relocation. While it may not be strictly needed the + SMM stub code relies on the FXSAVE area being non-zero to enable SSE + instructions within SMM mode. */ +static uint8_t fxsave_area_relocation[CONFIG_MAX_CPUS][FXSAVE_SIZE] +__attribute__((aligned(16))); + +/* + * Components that make up the SMRAM: + * 1. Save state - the total save state memory used + * 2. Stack - stacks for the CPUs in the SMM handler + * 3. Stub - SMM stub code for calling into handler + * 4. Handler - C-based SMM handler. + * + * The components are assumed to consist of one consecutive region. + */ + +/* These parameters are used by the SMM stub code. A pointer to the params + * is also passed to the C-base handler. */ +struct smm_stub_params { + u32 stack_size; + u32 stack_top; + u32 c_handler; + u32 c_handler_arg; + u32 fxsave_area; + u32 fxsave_area_size; + struct smm_runtime runtime; +} __packed; + +/* + * The stub is the entry point that sets up protected mode and stacks for each + * CPU. It then calls into the SMM handler module. It is encoded as an rmodule. + */ +extern unsigned char _binary_smmstub_start[]; + +/* Per CPU minimum stack size. */ +#define SMM_MINIMUM_STACK_SIZE 32 + +struct cpu_smm_info { + uint8_t active; + unsigned int smbase; + unsigned int entry; + unsigned int ss_start; + unsigned int code_start; + unsigned int code_end; +}; +struct cpu_smm_info cpus[CONFIG_MAX_CPUS] = { 0 }; + +/* + * This method creates a map of all the CPU entry points, save state locations + * and the beginning and end of code segments for each CPU. This map is used + * during relocation to properly align as many CPUs that can fit into the SMRAM + * region. For more information on how SMRAM works, refer to the latest Intel + * developer's manuals (volume 3, chapter 34). SMRAM is divided up into the + * following regions: + * +-----------------+ Top of SMRAM + * | | <- MSEG, FXSAVE + * +-----------------+ + * | common | + * | smi handler | 64K + * | | + * +-----------------+ + * | CPU 0 code seg | + * +-----------------+ + * | CPU 1 code seg | + * +-----------------+ + * | CPU x code seg | + * +-----------------+ + * | | + * | | + * +-----------------+ + * | stacks | + * +-----------------+ <- START of SMRAM + * + * The code below checks when a code segment is full and begins placing the remainder + * CPUs in the lower segments. The entry point for each CPU is smbase + 8000 + * and save state is smbase + 0x8000 + (0x8000 - state save size). Save state + * area grows downward into the CPUs entry point. Therefore staggering too many + * CPUs in one 32K block will corrupt CPU0's entry code as the save states move + * downward. + * input : smbase of first CPU (all other CPUs + * will go below this address) + * input : num_cpus in the system. The map will + * be created from 0 to num_cpus. + */ +static int smm_create_map(unsigned int smbase, unsigned int num_cpus, + const struct smm_loader_params *params) +{ + unsigned int i; + struct rmodule smm_stub; + unsigned int ss_size = params->per_cpu_save_state_size, stub_size; + unsigned int smm_entry_offset = params->smm_main_entry_offset; + unsigned int seg_count = 0, segments = 0, available; + unsigned int cpus_in_segment = 0; + unsigned int base = smbase; + + if (rmodule_parse(&_binary_smmstub_start, &smm_stub)) + printk(BIOS_ERR, "%s : unable to get SMM module size\n", __func__); + + stub_size = rmodule_memory_size(&smm_stub); + /* How many CPUs can fit into one segment? */ + available = 0xFFFF - smm_entry_offset - ss_size - stub_size; + if (available > 0) { + cpus_in_segment = available/ss_size; + /* minimum segments needed will always be 1*/ + segments = num_cpus / cpus_in_segment + 1; + printk(BIOS_DEBUG, + "%s: cpus in one segment %d\n", __func__, cpus_in_segment); + printk(BIOS_DEBUG, + "%s: min # of segments needed %d\n", __func__, segments); + } else { + printk(BIOS_ERR, + "%s: not enough space in SMM to setup all CPUs\n", __func__); + return -1; + } + + if (sizeof(cpus)/sizeof(struct cpu_smm_info) < cpus_in_segment * segments) { + printk(BIOS_ERR, + "%s: more CPUs than originally configured for\n", __func__); + return -1; + } + + for (i = 0; i < num_cpus; i++) { + cpus[i].smbase = base; + cpus[i].entry = base + smm_entry_offset; + cpus[i].ss_start = cpus[i].entry + (smm_entry_offset - ss_size); + cpus[i].code_start = cpus[i].entry; + cpus[i].code_end = cpus[i].entry + stub_size; + cpus[i].active = 1; + base -= ss_size; + seg_count++; + if (seg_count >= cpus_in_segment) { + base -= smm_entry_offset; + seg_count = 0; + } + } + + if (CONFIG_DEFAULT_CONSOLE_LOGLEVEL >= BIOS_DEBUG) { + seg_count = 0; + for (i = 0; i < num_cpus; i++) { + printk(BIOS_DEBUG, "CPU 0x%x\n", i); + printk(BIOS_DEBUG, + " smbase 0x%x entry 0x%x\n", + cpus[i].smbase, cpus[i].entry); + printk(BIOS_DEBUG, + " ss_start 0x%x code_end 0x%x\n", + cpus[i].ss_start, cpus[i].code_end); + seg_count++; + if (seg_count >= cpus_in_segment) { + printk(BIOS_DEBUG, + "-------------NEW CODE SEGMENT --------------\n"); + seg_count = 0; + } + } + } + return 1; +} + +/* + * This method expects the smm relocation map to be complete. + * This method does not read any HW registers, it simply uses a + * map that was created during SMM setup. + * input: cpu_num - cpu number which is used as an index into the + * map to return the smbase + */ +int smm_get_cpu_smbase(unsigned int cpu_num) +{ + if (cpu_num < CONFIG_MAX_CPUS) { + if (cpus[cpu_num].active) + return cpus[cpu_num].smbase; + } + return 0; +} + +/* + * This method assumes that at least 1 CPU has been set up from + * which it will place other CPUs below its smbase ensuring that + * save state does not clobber the first CPUs init code segment. The init + * code which is the smm stub code is the same for all CPUs. They enter + * smm, setup stacks (based on their apic id), enter protected mode + * and then jump to the common smi handler. The stack is allocated + * at the beginning of smram (aka tseg base, not smbase). The stack + * pointer for each CPU is calculated by using its apic id + * (code is in smm_stub.s) + * Each entry point will now have the same stub code which, sets up the CPU + * stack, enters protected mode and then jumps to the smi handler. It is + * important to enter protected mode before the jump because the "jump to + * address" might be larger than the 20bit address supported by real mode. + * SMI entry right now is in real mode. + * input: smbase - this is the smbase of the first cpu not the smbase + * where tseg starts (aka smram_start). All CPUs code segment + * and stack will be below this point except for the common + * SMI handler which is one segment above + * input: num_cpus - number of cpus that need relocation including + * the first CPU (though its code is already loaded) + * input: top of stack (stacks work downward by default in Intel HW) + * output: return -1, if runtime smi code could not be installed. In + * this case SMM will not work and any SMI's generated will + * cause a CPU shutdown or general protection fault becuause + * the appropriate smi handling code was not installed + */ +static void smm_place_entry_code(unsigned int smbase, unsigned int num_cpus, + unsigned int stack_top, const struct smm_loader_params *params) +{ + unsigned int i; + unsigned int size; + if (smm_create_map(smbase, num_cpus, params)) { + /* + * Ensure there was enough space and the last CPUs smbase + * did not encroach upon the stack. Stack top is smram start + * + size of stack. + */ + if (cpus[num_cpus].active) { + if (cpus[num_cpus - 1].smbase + + params->smm_main_entry_offset < stack_top) { + printk(BIOS_ERR, + "%s : need more stack space, stack encroachment\n", + __func__); + printk(BIOS_ERR, "%s : smbase %x, stack_top %x\n", + __func__, cpus[num_cpus].smbase, stack_top); + return; + } + } + } else { + printk(BIOS_ERR, "%s : unable to place smm entry code\n", __func__); + return; + } + + printk(BIOS_INFO, "%s : smbase %x, stack_top %x\n", + __func__, cpus[num_cpus-1].smbase, stack_top); + + /* start at 1, the first CPU stub code is already there */ + size = cpus[0].code_end - cpus[0].code_start; + for (i = 1; i < num_cpus; i++) { + memcpy((int *)cpus[i].code_start, (int *)cpus[0].code_start, size); + printk(BIOS_DEBUG, + "SMM Module: placing smm entry code at 0x%x, cpu # 0x%x\n", + cpus[i].code_start, i); + printk(BIOS_DEBUG, "%s copying from 0x%x to 0x%x 0x%x bytes\n", + __func__, cpus[0].code_start, cpus[i].code_start, size); + } + return; +} + +/* + * Place stacks in base -> base + size region, but ensure the stacks don't + * overlap the staggered entry points. + */ +static void *smm_stub_place_stacks(char *base, size_t size, + struct smm_loader_params *params) +{ + size_t total_stack_size; + char *stacks_top; + + /* If stack space is requested assume the space lives in the lower + * half of SMRAM. */ + total_stack_size = params->per_cpu_stack_size * + params->num_concurrent_stacks; + printk(BIOS_DEBUG, "%s cpus: %x : stack space: needed -> %x\n", + __func__, (int)params->num_concurrent_stacks, + (int)total_stack_size); + printk(BIOS_DEBUG, " available -> %x : per_cpu_stack_size : %x\n", + (int)size, (int)params->per_cpu_stack_size); + + /* There has to be at least one stack user. */ + if (params->num_concurrent_stacks < 1) + return NULL; + + /* Total stack size cannot fit. */ + if (total_stack_size > size) + return NULL; + + /* Stacks extend down to SMBASE */ + stacks_top = &base[total_stack_size]; + printk(BIOS_DEBUG, "%s : exit, stack_top %x\n", __func__, (int)stacks_top); + + return stacks_top; +} + +/* + * Place the staggered entry points for each CPU. The entry points are + * staggered by the per CPU SMM save state size extending down from + * SMM_ENTRY_OFFSET. + */ +static void smm_stub_place_staggered_entry_points(char *base, + const struct smm_loader_params *params, const struct rmodule *smm_stub) +{ + size_t stub_entry_offset; + + stub_entry_offset = rmodule_entry_offset(smm_stub); + /* Each CPU now has its own stub code, which enters protected mode, + * sets up the stack, and then jumps to common SMI handler + */ + if (params->num_concurrent_save_states > 1 || stub_entry_offset != 0) { + smm_place_entry_code((int)base, params->num_concurrent_save_states, + (int)params->stack_top, params); + } +} + +/* + * The stub setup code assumes it is completely contained within the + * default SMRAM size (0x10000) for the default SMI handler (entry at + * 0x30000), but no assumption should be made for the permanent SMI handler. + * The placement of CPU entry points for permanent handler are determined + * by the number of CPUs in the system and the amount of SMRAM. + * There are potentially 3 regions to place + * within the default SMRAM size: + * 1. Save state areas + * 2. Stub code + * 3. Stack areas + * + * The save state and stack areas are treated as contiguous for the number of + * concurrent areas requested. The save state always lives at the top of the + * the CPUS smbase (and the entry point is at offset 0x8000. This allows only a certain + * number of CPUs with staggered entry points until the save state area comes + * down far enough to overwrite/corrupt the entry code (stub code). Therefore, + * an SMM map is created to avoid this corruption, see smm_create_map above. + * This module setup code works for the default SMM handler setup and the + * permanent SMM handler. + */ +static int smm_module_setup_stub(void *smbase, size_t smm_size, + struct smm_loader_params *params, + void *fxsave_area) +{ + size_t total_save_state_size; + size_t smm_stub_size; + size_t stub_entry_offset; + char *smm_stub_loc; + void *stacks_top; + size_t size; + char *base; + size_t i; + struct smm_stub_params *stub_params; + struct rmodule smm_stub; + unsigned int total_size_all; + base = smbase; + size = smm_size; + + /* The number of concurrent stacks cannot exceed CONFIG_MAX_CPUS. */ + if (params->num_concurrent_stacks > CONFIG_MAX_CPUS) { + printk(BIOS_ERR, "%s : not enough stacks\n", __func__); + return -1; + } + + /* Fail if can't parse the smm stub rmodule. */ + if (rmodule_parse(&_binary_smmstub_start, &smm_stub)) { + printk(BIOS_ERR, "%s : unable to parse smm stub\n", __func__); + return -1; + } + + /* Adjust remaining size to account for save state. */ + total_save_state_size = params->per_cpu_save_state_size * + params->num_concurrent_save_states; + if (total_save_state_size > size) { + printk(BIOS_ERR, + "%s:more state save space needed:need -> %x:available->%x\n", + __func__, (int)total_save_state_size, (int)size); + return -1; + } + + size -= total_save_state_size; + + /* The save state size encroached over the first SMM entry point. */ + if (size <= params->smm_main_entry_offset) { + printk(BIOS_ERR, "%s:encroachment over SMM entry point\n", __func__); + printk(BIOS_ERR, "%s:state save size: %x : smm_entry_offset -> %x\n", + __func__, (int)size, params->smm_main_entry_offset); + return -1; + } + + /* Need a minimum stack size and alignment. */ + if (params->per_cpu_stack_size <= SMM_MINIMUM_STACK_SIZE || + (params->per_cpu_stack_size & 3) != 0) { + printk(BIOS_ERR, "%s : need minimum stack size\n", __func__); + return -1; + } + + smm_stub_loc = NULL; + smm_stub_size = rmodule_memory_size(&smm_stub); + stub_entry_offset = rmodule_entry_offset(&smm_stub); + + /* Put the stub at at the main entry point */ + smm_stub_loc = &base[params->smm_main_entry_offset]; + + /* Stub is too big to fit. */ + if (smm_stub_size > (size - params->smm_main_entry_offset)) { + printk(BIOS_ERR, "%s : stub is too big to fit\n", __func__); + return -1; + } + + /* The stacks, if requested, live in the lower half of SMRAM space + * for default handler, but for relocated handler it lives at the beginning + * of SMRAM which is TSEG base + */ + size = params->num_concurrent_stacks*params->per_cpu_stack_size; + stacks_top = smm_stub_place_stacks((char *)params->smram_start, size, params); + if (stacks_top == NULL) { + printk(BIOS_ERR, "%s : not enough space for stacks\n", __func__); + printk(BIOS_ERR, "%s : ....need -> %x : available -> %x\n", __func__, + (int)base, (int)size); + return -1; + } + params->stack_top = stacks_top; + /* Load the stub. */ + if (rmodule_load(smm_stub_loc, &smm_stub)) { + printk(BIOS_ERR, "%s : load module failed\n", __func__); + return -1; + } + + smm_stub_place_staggered_entry_points(base, params, &smm_stub); + + /* Setup the parameters for the stub code. */ + stub_params = rmodule_parameters(&smm_stub); + stub_params->stack_top = (uintptr_t)stacks_top; + stub_params->stack_size = params->per_cpu_stack_size; + stub_params->c_handler = (uintptr_t)params->handler; + stub_params->c_handler_arg = (uintptr_t)params->handler_arg; + stub_params->fxsave_area = (uintptr_t)fxsave_area; + stub_params->fxsave_area_size = FXSAVE_SIZE; + stub_params->runtime.smbase = (uintptr_t)smbase; + stub_params->runtime.smm_size = smm_size; + stub_params->runtime.save_state_size = params->per_cpu_save_state_size; + stub_params->runtime.num_cpus = params->num_concurrent_stacks; + + printk(BIOS_DEBUG, "%s : stack_end = 0x%x\n", + __func__, (int)stub_params->runtime.smbase); + printk(BIOS_DEBUG, + "%s : stack_top = 0x%x\n", __func__, (int)stub_params->stack_top); + printk(BIOS_DEBUG, "%s : stack_size = 0x%x\n", + __func__, (int)stub_params->stack_size); + printk(BIOS_DEBUG, "%s : runtime.smbase = 0x%x\n", + __func__, (int)stub_params->runtime.smbase); + printk(BIOS_DEBUG, "%s : runtime.start32_offset = 0x%x\n", __func__, + (int)stub_params->runtime.start32_offset); + printk(BIOS_DEBUG, "%s : runtime.smm_size = 0x%x\n", + __func__, (int)smm_size); + printk(BIOS_DEBUG, "%s : per_cpu_save_state_size = 0x%x\n", + __func__, (int)stub_params->runtime.save_state_size); + printk(BIOS_DEBUG, "%s : num_cpus = 0x%x\n", __func__, + (int)stub_params->runtime.num_cpus); + printk(BIOS_DEBUG, "%s : total_save_state_size = 0x%x\n", + __func__, (int)(stub_params->runtime.save_state_size* + stub_params->runtime.num_cpus)); + total_size_all = (int)stub_params->stack_size + + (int)(stub_params->runtime.save_state_size* + stub_params->runtime.num_cpus); + printk(BIOS_DEBUG, "%s : total_size_all = 0x%x\n", __func__, + total_size_all); + + /* Initialize the APIC id to CPU number table to be 1:1 */ + for (i = 0; i < params->num_concurrent_stacks; i++) + stub_params->runtime.apic_id_to_cpu[i] = i; + + /* Allow the initiator to manipulate SMM stub parameters. */ + params->runtime = &stub_params->runtime; + + printk(BIOS_DEBUG, "SMM Module: stub loaded at %p. Will call %p(%p)\n", + smm_stub_loc, params->handler, params->handler_arg); + return 0; +} + +/* + * smm_setup_relocation_handler assumes the callback is already loaded in + * memory. i.e. Another SMM module isn't chained to the stub. The other + * assumption is that the stub will be entered from the default SMRAM + * location: 0x30000 -> 0x40000. + */ +int smm_setup_relocation_handler(struct smm_loader_params *params) +{ + void *smram = (void *)(SMM_DEFAULT_BASE); + printk(BIOS_SPEW, "%s: enter\n", __func__); + /* There can't be more than 1 concurrent save state for the relocation + * handler because all CPUs default to 0x30000 as SMBASE. */ + if (params->num_concurrent_save_states > 1) + return -1; + + /* A handler has to be defined to call for relocation. */ + if (params->handler == NULL) + return -1; + + /* Since the relocation handler always uses stack, adjust the number + * of concurrent stack users to be CONFIG_MAX_CPUS. */ + if (params->num_concurrent_stacks == 0) + params->num_concurrent_stacks = CONFIG_MAX_CPUS; + + params->smm_main_entry_offset = SMM_ENTRY_OFFSET; + params->smram_start = SMM_DEFAULT_BASE; + params->smram_end = SMM_DEFAULT_BASE + SMM_DEFAULT_SIZE; + return smm_module_setup_stub(smram, SMM_DEFAULT_SIZE, + params, fxsave_area_relocation); + printk(BIOS_SPEW, "%s: exit\n", __func__); +} + +/* + *The SMM module is placed within the provided region in the following + * manner: + * +-----------------+ <- smram + size + * | BIOS resource | + * | list (STM) | + * +-----------------+ + * | fxsave area | + * +-----------------+ + * | smi handler | + * | ... | + * +-----------------+ <- cpu0 + * | stub code | <- cpu1 + * | stub code | <- cpu2 + * | stub code | <- cpu3, etc + * | | + * | | + * | | + * | stacks | + * +-----------------+ <- smram start + + * It should be noted that this algorithm will not work for + * SMM_DEFAULT_SIZE SMRAM regions such as the A segment. This algorithm + * expects a region large enough to encompass the handler and stacks + * as well as the SMM_DEFAULT_SIZE. + */ +int smm_load_module(void *smram, size_t size, struct smm_loader_params *params) +{ + struct rmodule smm_mod; + size_t total_stack_size; + size_t handler_size; + size_t module_alignment; + size_t alignment_size; + size_t fxsave_size; + void *fxsave_area; + size_t total_size = 0; + char *base; + + if (size <= SMM_DEFAULT_SIZE) + return -1; + + /* Load main SMI handler at the top of SMRAM + * everything else will go below + */ + base = smram; + base += size; + params->smram_start = (uintptr_t)smram; + params->smram_end = params->smram_start + size; + params->smm_main_entry_offset = SMM_ENTRY_OFFSET; + + /* Fail if can't parse the smm rmodule. */ + if (rmodule_parse(&_binary_smm_start, &smm_mod)) + return -1; + + /* Clear SMM region */ + if (CONFIG(DEBUG_SMI)) + memset(smram, 0xcd, size); + + total_stack_size = params->per_cpu_stack_size * + params->num_concurrent_stacks; + total_size += total_stack_size; + /* Stacks are the base of SMRAM */ + params->stack_top = smram + total_stack_size; + + /* MSEG starts at the top of SMRAM and works down */ + if (CONFIG(STM)) { + base -= CONFIG_MSEG_SIZE + CONFIG_BIOS_RESOURCE_LIST_SIZE; + total_size += CONFIG_MSEG_SIZE + CONFIG_BIOS_RESOURCE_LIST_SIZE; + } + + /* FXSAVE goes below MSEG */ + if (CONFIG(SSE)) { + fxsave_size = FXSAVE_SIZE * params->num_concurrent_stacks; + fxsave_area = base - fxsave_size; + base -= fxsave_size; + total_size += fxsave_size; + } else { + fxsave_size = 0; + fxsave_area = NULL; + } + + + handler_size = rmodule_memory_size(&smm_mod); + base -= handler_size; + total_size += handler_size; + module_alignment = rmodule_load_alignment(&smm_mod); + alignment_size = module_alignment - + ((uintptr_t)base % module_alignment); + if (alignment_size != module_alignment) { + handler_size += alignment_size; + base += alignment_size; + } + + printk(BIOS_DEBUG, + "%s : total_smm_space_needed 0x%x, available -> 0x%x\n", + __func__, (int)total_size, (int)size); + + /* Does the required amount of memory exceed the SMRAM region size? */ + if (total_size > size) { + printk(BIOS_ERR, + "%s : need more SMRAM\n", __func__); + return -1; + } + if (handler_size > SMM_CODE_SEGMENT_SIZE) { + printk(BIOS_ERR, "%s : increase SMM_CODE_SEGMENT_SIZE: handler_size = 0x%0x\n", + __func__, (int)handler_size); + return -1; + } + + if (rmodule_load(base, &smm_mod)) + return -1; + + params->handler = rmodule_entry(&smm_mod); + params->handler_arg = rmodule_parameters(&smm_mod); + + printk(BIOS_DEBUG, "%s : smram_start: 0x%x\n", + __func__, (int)smram); + printk(BIOS_DEBUG, "%s : smram_end: 0x%x\n", + __func__, (int)smram + (int)size); + printk(BIOS_DEBUG, "%s : stack_top: 0x%x\n", + __func__, (int)params->stack_top); + printk(BIOS_DEBUG, "%s : handler start 0x%x\n", + __func__, (int)params->handler); + printk(BIOS_DEBUG, "%s : handler_size 0x%x\n", + __func__, (int)handler_size); + printk(BIOS_DEBUG, "%s : handler_arg 0x%x\n", + __func__, (int)params->handler_arg); + printk(BIOS_DEBUG, "%s : fxsave_area 0x%x\n", + __func__, (int)fxsave_area); + printk(BIOS_DEBUG, "%s : fxsave_size 0x%x\n", + __func__, (int)fxsave_size); + printk(BIOS_DEBUG, "%s : CONFIG_MSEG_SIZE 0x%x\n", + __func__, (int)CONFIG_MSEG_SIZE); + printk(BIOS_DEBUG, "%s : CONFIG_BIOS_RESOURCE_LIST_SIZE 0x%x\n", + __func__, (int)CONFIG_BIOS_RESOURCE_LIST_SIZE); + + /* CPU 0 smbase goes first, all other CPUs + * will be staggered below + */ + base -= SMM_CODE_SEGMENT_SIZE; + printk(BIOS_DEBUG, "%s : cpu0 entry: 0x%x\n", + __func__, (int)base); + params->smm_entry = (uintptr_t)base + params->smm_main_entry_offset; + return smm_module_setup_stub(base, size, params, fxsave_area); +} diff --git a/src/include/cpu/x86/smm.h b/src/include/cpu/x86/smm.h index a3101e5..7838223 100644 --- a/src/include/cpu/x86/smm.h +++ b/src/include/cpu/x86/smm.h @@ -128,6 +128,12 @@ * 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 @@ 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) +int 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); -- To view, visit https://review.coreboot.org/c/coreboot/+/43684 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I00a23a5f2a46110536c344254868390dbb71854c Gerrit-Change-Number: 43684 Gerrit-PatchSet: 1 Gerrit-Owner: Rocky Phagura Gerrit-MessageType: newchange

8 50

Change in coreboot[master]: cpu/qemu-x86: Allow up to 255 cores
by build bot (Jenkins) (Code Review) 07 Apr '22

07 Apr '22

build bot (Jenkins) has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/63483 ) Change subject: cpu/qemu-x86: Allow up to 255 cores ...................................................................... Patch Set 4: Verified+1 -- To view, visit https://review.coreboot.org/c/coreboot/+/63483 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I9eea91fb09f47de8b06de9fa7eb2ad66ef4dc7e2 Gerrit-Change-Number: 63483 Gerrit-PatchSet: 4 Gerrit-Owner: Arthur Heymans <arthur(a)aheymans.xyz> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Comment-Date: Thu, 07 Apr 2022 22:14:04 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

1 0

Change in coreboot[master]: arch/x86/smbios.c: Fix for CONFIG_MAX_CPUS > 255
by build bot (Jenkins) (Code Review) 07 Apr '22

07 Apr '22

build bot (Jenkins) has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/63482 ) Change subject: arch/x86/smbios.c: Fix for CONFIG_MAX_CPUS > 255 ...................................................................... Patch Set 4: Verified+1 -- To view, visit https://review.coreboot.org/c/coreboot/+/63482 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I079c99006fea95ba3dc2fb02c95a3747af55e218 Gerrit-Change-Number: 63482 Gerrit-PatchSet: 4 Gerrit-Owner: Arthur Heymans <arthur(a)aheymans.xyz> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Comment-Date: Thu, 07 Apr 2022 22:13:45 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

1 0

Change in coreboot[master]: cpu/x86/smm_module_loader: Update logging
by build bot (Jenkins) (Code Review) 07 Apr '22

07 Apr '22

build bot (Jenkins) has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/63481 ) Change subject: cpu/x86/smm_module_loader: Update logging ...................................................................... Patch Set 4: Verified+1 -- To view, visit https://review.coreboot.org/c/coreboot/+/63481 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I84d49a394cc53d78f1e1d3936502ac16810daf9f Gerrit-Change-Number: 63481 Gerrit-PatchSet: 4 Gerrit-Owner: Arthur Heymans <arthur(a)aheymans.xyz> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Comment-Date: Thu, 07 Apr 2022 22:08:36 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

1 0

Change in coreboot[master]: [WIP] mb/google,intel: Split chromeos.c files
by Tim Wawrzynczak (Code Review) 07 Apr '22

07 Apr '22

Attention is currently required from: Jason Glenesk, Marshall Dawson, Nick Vaccaro, Kyösti Mälkki, Fred Reitberger, Felix Held. Tim Wawrzynczak has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/59011 ) Change subject: [WIP] mb/google,intel: Split chromeos.c files ...................................................................... Patch Set 8: (1 comment) File src/mainboard/google/eve/chromeos.c: https://review.coreboot.org/c/coreboot/+/59011/comment/2cf01f36_62af0b74 PS6, Line 26: CROS_GPIO_WP_AH(GPIO_PCH_WP, CROS_GPIO_DEVICE_NAME), > Ah, thanks for the link. From ReadGPIO() in crosssyste_arch.c line 790_ […] Yes, that is true, I am not sure if/why these are still required anymore, because crossystem will fall back on some of them, e.g. https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/pla… -- To view, visit https://review.coreboot.org/c/coreboot/+/59011 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I71a02c5fa1b256316b86b673660bf22dfd284f7f Gerrit-Change-Number: 59011 Gerrit-PatchSet: 8 Gerrit-Owner: Kyösti Mälkki <kyosti.malkki(a)gmail.com> Gerrit-Reviewer: Felix Held <felix-coreboot(a)felixheld.de> Gerrit-Reviewer: Fred Reitberger <reitbergerfred(a)gmail.com> Gerrit-Reviewer: Jason Glenesk <jason.glenesk(a)gmail.com> Gerrit-Reviewer: Marshall Dawson <marshalldawson3rd(a)gmail.com> Gerrit-Reviewer: Nick Vaccaro <nvaccaro(a)chromium.org> Gerrit-Reviewer: Tim Wawrzynczak <twawrzynczak(a)chromium.org> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: Paul Menzel <paulepanter(a)mailbox.org> Gerrit-Attention: Jason Glenesk <jason.glenesk(a)gmail.com> Gerrit-Attention: Marshall Dawson <marshalldawson3rd(a)gmail.com> Gerrit-Attention: Nick Vaccaro <nvaccaro(a)chromium.org> Gerrit-Attention: Kyösti Mälkki <kyosti.malkki(a)gmail.com> Gerrit-Attention: Fred Reitberger <reitbergerfred(a)gmail.com> Gerrit-Attention: Felix Held <felix-coreboot(a)felixheld.de> Gerrit-Comment-Date: Thu, 07 Apr 2022 22:04:53 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: Tim Wawrzynczak <twawrzynczak(a)chromium.org> Comment-In-Reply-To: Kyösti Mälkki <kyosti.malkki(a)gmail.com> Gerrit-MessageType: comment

1 0

Change in coreboot[master]: cpu/x86/mp_init.c: Drop 'real' vs 'used' save state
by build bot (Jenkins) (Code Review) 07 Apr '22

07 Apr '22

build bot (Jenkins) has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/63479 ) Change subject: cpu/x86/mp_init.c: Drop 'real' vs 'used' save state ...................................................................... Patch Set 4: Verified+1 -- To view, visit https://review.coreboot.org/c/coreboot/+/63479 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: Ia0002a33b6d0f792d8d78cf625fd7e830e3e50fc Gerrit-Change-Number: 63479 Gerrit-PatchSet: 4 Gerrit-Owner: Arthur Heymans <arthur(a)aheymans.xyz> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Comment-Date: Thu, 07 Apr 2022 22:04:50 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

1 0

Change in coreboot[master]: cpu/x86/smm_module_load: Rewrite setup_stub
by build bot (Jenkins) (Code Review) 07 Apr '22

07 Apr '22

build bot (Jenkins) has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/63478 ) Change subject: cpu/x86/smm_module_load: Rewrite setup_stub ...................................................................... Patch Set 4: Verified+1 -- To view, visit https://review.coreboot.org/c/coreboot/+/63478 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I42ef9d6a30f3039f25e2cde975086a1365ca4182 Gerrit-Change-Number: 63478 Gerrit-PatchSet: 4 Gerrit-Owner: Arthur Heymans <arthur(a)aheymans.xyz> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Comment-Date: Thu, 07 Apr 2022 22:01:21 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

1 0

Change in coreboot[master]: soc/intel/common: implement ioc driver
by Wonkyu Kim (Code Review) 07 Apr '22

07 Apr '22

Attention is currently required from: Jamie Ryu, Wonkyu Kim, Subrata Banik, Ethan Tsao, Ravishankar Sarawadi, Tim Wawrzynczak, Paul Menzel, Nick Vaccaro. Hello build bot (Jenkins), Jamie Ryu, Subrata Banik, Ethan Tsao, Ravishankar Sarawadi, Nick Vaccaro, Tim Wawrzynczak, I'd like you to reexamine a change. Please visit https://review.coreboot.org/c/coreboot/+/63198 to look at the new patch set (#8). Change subject: soc/intel/common: implement ioc driver ...................................................................... soc/intel/common: implement ioc driver DMI is changed to IOC(I/O Cache) in MTL Reference: 643504 MTL FAS section 7.5.2 and reference FSP code. https://github.com/otcshare/CCG-MTL-Generic-PSS/blob/master/ ClientOneSiliconPkg/IpBlock/Ioc/IncludePrivate/Register/IocRegs.h TEST=Build and boot to OS for TGL and MTL Signed-off-by: Wonkyu Kim <wonkyu.kim(a)intel.com> Change-Id: I768027c2ca78310c03845f70f17df19dc8cd0982 --- M src/soc/intel/common/block/gpmr/gpmr.c M src/soc/intel/common/block/include/intelblocks/gpmr.h A src/soc/intel/common/block/include/intelblocks/ioc.h A src/soc/intel/common/block/include/intelblocks/ioc_gpmr.h A src/soc/intel/common/block/ioc/Kconfig A src/soc/intel/common/block/ioc/Makefile.inc A src/soc/intel/common/block/ioc/ioc.c 7 files changed, 78 insertions(+), 2 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/98/63198/8 -- To view, visit https://review.coreboot.org/c/coreboot/+/63198 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I768027c2ca78310c03845f70f17df19dc8cd0982 Gerrit-Change-Number: 63198 Gerrit-PatchSet: 8 Gerrit-Owner: Wonkyu Kim <wonkyu.kim(a)intel.com> Gerrit-Reviewer: Ethan Tsao <ethan.tsao(a)intel.com> Gerrit-Reviewer: Jamie Ryu <jamie.m.ryu(a)intel.com> Gerrit-Reviewer: Nick Vaccaro <nvaccaro(a)google.com> Gerrit-Reviewer: Ravishankar Sarawadi <ravishankar.sarawadi(a)intel.com> Gerrit-Reviewer: Subrata Banik <subratabanik(a)google.com> Gerrit-Reviewer: Tim Wawrzynczak <twawrzynczak(a)google.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: Angel Pons <th3fanbus(a)gmail.com> Gerrit-CC: Paul Menzel <paulepanter(a)mailbox.org> Gerrit-CC: Tim Wawrzynczak <twawrzynczak(a)chromium.org> Gerrit-Attention: Jamie Ryu <jamie.m.ryu(a)intel.com> Gerrit-Attention: Wonkyu Kim <wonkyu.kim(a)intel.com> Gerrit-Attention: Subrata Banik <subratabanik(a)google.com> Gerrit-Attention: Ethan Tsao <ethan.tsao(a)intel.com> Gerrit-Attention: Ravishankar Sarawadi <ravishankar.sarawadi(a)intel.com> Gerrit-Attention: Tim Wawrzynczak <twawrzynczak(a)chromium.org> Gerrit-Attention: Paul Menzel <paulepanter(a)mailbox.org> Gerrit-Attention: Nick Vaccaro <nvaccaro(a)google.com> Gerrit-Attention: Tim Wawrzynczak <twawrzynczak(a)google.com> Gerrit-MessageType: newpatchset

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

coreboot-gerrit April 2022