ExtINT is related to external PIC mode i8259 interrupts,
they should be delivered to one CPU (BSP) only.
Change-Id: I78490d2cbe3d9f52e10ef2471508263fd6c146ba
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42434
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The bits REMOTE_IRR and SEND_PENDING are documented as read-only,
and reserved bits should not be modified either.
Change-Id: I6bcb9eb990debe169340a0bfe662158b62a8f4dc
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55700
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The bit LAPIC_SPIV_ENABLE returns 0 after reset even though
LAPIC has not been temporarily disabled.
Change-Id: Id261bc68fe9d1b1b0e5a3ef599a8f33a686d283b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55699
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Only the enable_lapic() part is required while doing
SMP init. Also disable_lapic() must not be called if
we rely on LAPIC for timer source.
Change-Id: Ib5e37c1a0a91fa4e9542141aa74f1c1876fee94e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55261
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
There is currently a fundamental flaw in the current cpu_info()
implementation. It assumes that current stack is CONFIG_STACK_SIZE
aligned. This assumption breaks down when performing SMM relocation.
The first step in performing SMM relocation is changing the SMBASE. This
is accomplished by installing the smmstub at 0x00038000, which is the
default SMM entry point. The stub is configured to set up a new stack
with the size of 1 KiB (CONFIG_SMM_STUB_STACK_SIZE), and an entry point
of smm_do_relocation located in RAMSTAGE RAM.
This means that when smm_do_relocation is executed, it is running in SMM
with a different sized stack. When cpu_info() gets called it will be
using CONFIG_STACK_SIZE to calculate the location of the cpu_info
struct. This results in reading random memory. Since cpu_info() has to
run in multiple environments, we can't use a compile time constant to
locate the cpu_info struct.
This CL introduces a new way of locating cpu_info. It uses a per-cpu
segment descriptor that points to a per-cpu segment that is allocated on
the stack. By using a segment descriptor to point to the per-cpu data,
we no longer need to calculate the location of the cpu_info struct. This
has the following advantages:
* Stacks no longer need to be CONFIG_STACK_SIZE aligned.
* Accessing an unconfigured segment will result in an exception. This
ensures no one can call cpu_info() from an unsupported environment.
* Segment selectors are cleared when entering SMM and restored when
leaving SMM.
* There is a 1:1 mapping between cpu and cpu_info. When using
COOP_MULTITASKING, a new cpu_info is currently allocated at the top of
each thread's stack. This no longer needs to happen.
This CL guards most of the code with CONFIG(CPU_INFO_V2). I did this so
reviewers can feel more comfortable knowing most of the CL is a no-op. I
would eventually like to remove most of the guards though.
This CL does not touch the LEGACY_SMP_INIT code path. I don't have any
way of testing it.
The %gs segment was chosen over the %fs segment because it's what the
linux kernel uses for per-cpu data in x86_64 mode.
BUG=b:194391185, b:179699789
TEST=Boot guybrush with CPU_INFO_V2 and verify BSP and APs have correct
%gs segment. Verify cpu_info looks sane. Verify booting to the OS
works correctly with COOP_MULTITASKING enabled.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I79dce9597cb784acb39a96897fb3c2f2973bfd98
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57627
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Peers <epeers@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
These issues were found and fixed by codespell, a useful tool for
finding spelling errors.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I5b8ecdfe75d99028fee820a2034466a8ad1c5e63
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58080
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The %fs and %gs segment are typically used to implement thread local
storage or cpu local storage. We don't currently use these in coreboot,
so there is no reason to map them. By setting the segment index to 0,
it disables the segment. If an instruction tries to read from one of
these segments an exception will be raised.
The end goal is to make cpu_info() use the %gs segment. This will remove
the stack alignment requirements and fix smm_do_relocation.
BUG=b:194391185, b:179699789
TEST=Boot guybrush to OS
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Iaa376e562acc6bd1dfffb7a23bdec82aa474c1d5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57860
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Peers <epeers@google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This will help reduce duplication and make it easier to add new members
to the cpu_info struct.
BUG=b:194391185, b:179699789
TEST=Compare assembly of romstage and ramstage before and after
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I31f264f4bb8b605fa3cb3bfff0d9bf79224072aa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57859
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
It took me a while to understand the SMM set up flow. This adds a
clarifying comment.
BUG=b:194391185, b:179699789
TEST=None
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I9c73e416b8c583cf870e7a29b0bd7dcc99c2f5f4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57858
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
The code under `cpu/x86/tsc` is only compiled in when its `Makefile.inc`
is included from platform (CPU/SoC) code and the `UDELAY_TSC` Kconfig
option is enabled.
Include `cpu/x86/tsc/Makefile.inc` once from `cpu/x86/Makefile.inc` and
drop the now-redundant inclusions from platform code. Also, deduplicate
the `UDELAY_TSC` guards.
Change-Id: I41e96026f37f19de954fd5985b92a08cb97876c1
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57456
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch ensures mp_run_on_all_aps() is passing 'MP_RUN_ON_ALL_CPUS'
macro rather hardcoding `0` while running `func` on all APs.
Change-Id: Icd34371c0d4349e1eefe945958eda957c4794707
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57342
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Since current AMD SoCs don't need some wait time between INIT and SIPI,
we can skip the 10ms wait there, which improves the boot time a bit.
before: CPU_CLUSTER: 0 init finished in 632 msecs
after: CPU_CLUSTER: 0 init finished in 619 msecs
mpinit still works on Mandolin and all CPU cores show up and are usable.
This also doesn't change the binary in a timeless build for boards/SoCs
that don't select X86_AMD_INIT_SIPI which I verified for lenovo/x230.
BUG=b:193885336
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I1e044776f45021742a88a5e369a74383c1baaab6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56533
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
The alignment for `struct cpu_info` is wrong on x86_64. c_start.S uses
the `push` instruction when setting up the cpu_info struct. This
instruction will push 8 bytes but `unsigned int` is 4 bytes. By making
it a `size_t` we get the correct size for both x86_32 and x86_64.
BUG=b:179699789
TEST=Boot guybrush to the OS
Suggested-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I8ef311aaa8333ccf8a5b3f1f0e852bb26777671c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56573
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Expand NO_EARLY_BOOTBLOCK_POSTCODES to all of the early assembly code in
bootblock.
BUG=b:191370340
TEST: Build with & without the option enabled
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: Idb4a96820d5c391fc17a0f0dcccd519d4881b78c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55731
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This commit adds a method called `mainboard_smi_finalize` which provides
a mechanism for a mainboard to execute some code as part of the finalize
method in the SMM stage before SoC does its finalization.
BUG=b:191189275
BRANCH=None
TEST=Implement `mainboard_smi_finalize` on lalala and verify that the
code executes in SMM.
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Change-Id: If1ee63431e3c2a5831a4656c3a361229acff3f42
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55649
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Trigger mode LAPIC_INT_LEVELTRIG was only used with LAPIC_DM_INIT,
specifically for (obsolete) Init Level De-assert.
Level LAPIC_INT_ASSERT is required to be set for all other delivery
modes other than LAPIC_DM_INIT.
This reverts the two above changes that X2APIC mode support introduced
to the IPI for LAPIC_DM_SMI.
Change-Id: I7264f39143cc6edb7a9687d0bd763cb2703a8265
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55197
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In x86_64 code every function call consumes 32byte of stack with
no stack local variables being used. That limits the function call depth
in SMM to 32 or less.
Double the stack size to prevent overwriting the stack canary as seen
on HP8200 and x86_64 enabled.
Change-Id: Iee202ba2ae609a474d0eb3b06f49690f33f4eda8
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55449
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This fixes a hard to debug hang that could occur in any stage, but in
the end it follows simple rules and is easy to fix.
In long mode the 32bit displacement addressing used on 'mov' and 'lea'
instructions is sign-extended. Those instructions can be found using
readelf on the stage and searching for relocation type R_X86_64_32S.
The sign extension is no issue when either running in protected mode or
the code module and thus the address is below 2GiB. If the address is
greater than 2GiB, as usually the case for code in TSEG, the higher
address bits [64:32] are all set to 1 and the effective address is
pointing to memory not paged. Accessing this memory will cause a page
fault, which isn't handled either.
To prevent such problems
- disable R_AMD64_32S relocations in rmodtool
- add comment explaining why it's not allowed
- use the pseudo op movabs, which doesn't use 32bit displacement addressing
- Print a useful error message if such a reloc is present in the code
Fixes a crash in TSEG and when in long mode seen on Intel Sandybridge.
Change-Id: Ia5f5a9cde7c325f67b12e3a8e9a76283cc3870a3
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55448
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Note that there are assumptions about LAPIC MMIO location
in both AMD and Intel sources in coreboot proper.
Change-Id: I2c668f5f9b93d170351c00d77d003c230900e0b4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55194
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Function is needed with PARALLEL_MP and excluding guard will
be added to the source file.
The incompatibilities with X2APIC_SUPPORT have been fixed
so the exclusion is removed here too.
Change-Id: I5696da4dfe98579a3b37a027966b6758f22574aa
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55193
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
They are not __always_inline and specially enable_lapic()
will become more complex to support X2APIC state changes.
Change-Id: Ic180fa8b36e419aba07e1754d4bf48c9dfddb2f3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55258
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Allows compile-time optimisation on platforms that do not wish
to enable runtime checking of X2APIC.
Legacy lapic_cpu_init() is incompatible so there is dependency
on PARALLEL_MP. Also stop_this_cpu() is incompatible, so there
is dependency on !AP_IN_SIPI_WAIT.
Since the code actually lacks enablement of X2APIC (apparently
assuming the blob has done it) and the other small flaws pointed
out in earlier reviews, X2APIC_RUNTIME is not selected per
default on any platform yet.
Change-Id: I8269f9639ee3e89a2c2b4178d266ba2dac46db3f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55073
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
For the purpose of LAPIC IPI messaging it is not required to
evaluate if IOAPIC is enabled. The necessary enable_lapic()
will still be called as part of setup_lapic() within cpu init.
Change-Id: I8b6a34e39f755452f0af63ae0ced7279747c28fc
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55251
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
It was not used, platforms should move away from LEGACY_SMP_INIT
instead of maintaining this.
Change-Id: Id89ec4bb0bdc056ac328f31397e4fab02742e444
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55204
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The 64-bit compiler x86_64-linux-gnu-gcc-10 aborts the build with the
format warning below:
CC ramstage/cpu/x86/smm/smm_module_loader.o
src/cpu/x86/smm/smm_module_loader.c:415:42: error: format '%lx' expects argument of type 'long unsigned int', but argument 4 has type 'u32' {aka 'unsigned int'} [-Werror=format=]
415 | printk(BIOS_DEBUG, "%s: stack_end = 0x%lx\n",
| ~~^
| |
| long unsigned int
| %x
416 | __func__, stub_params->stack_top - total_stack_size);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| u32 {aka unsigned int}
The size of `size_t` differs between i386-elf (32-bit) and
x86_64-elf/x86_64-linux-gnu (64-bit).
Unfortunately, coreboot hardcodes
src/include/inttypes.h:#define PRIx32 "x"
so `PRIx32` cannot be used.
There use `z` as length modifier, as size_t should be always big enough
to hold the value.
Found-by: x86_64-linux-gnu-gcc-10 (Debian 10.2.1-6) 10.2.1 20210110
Fixes: afb7a814 ("cpu/x86/smm: Introduce SMM module loader version 2")
Change-Id: Ib504bc5e5b19f62d4702b7f485522a2ee3d26685
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54343
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The 64-bit compiler x86_64-linux-gnu-gcc-10 aborts the build with the
format warning below:
CC ramstage/cpu/x86/smm/smm_module_loader.o
src/cpu/x86/smm/smm_module_loader.c: In function 'smm_module_setup_stub':
src/cpu/x86/smm/smm_module_loader.c:360:70: error: format '%lx' expects argument of type 'long unsigned int', but argument 5 has type 'unsigned int' [-Werror=format=]
360 | printk(BIOS_ERR, "%s: state save size: %zx : smm_entry_offset -> %lx\n",
| ~~^
| |
| long unsigned int
| %x
As `size_t` is defined as `long unsigned int` in i386-elf (32-bit), the
length modifier `l` matches there. With x86_64-elf/x86_64-linux-gnu
(64-bit) and `-m32` `size_t` is defined as `unsigned int` resulting in a
type mismatch. So, use the correct length modifier `z` for the type
`size_t`.
Found-by: x86_64-linux-gnu-gcc-10 (Debian 10.2.1-6) 10.2.1 20210110
Fixes: afb7a814 ("cpu/x86/smm: Introduce SMM module loader version 2")
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Change-Id: I4172e0f4dc40437250da89b7720a5c1e5fbab709
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54342
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
The 64-bit compiler x86_64-linux-gnu-gcc-10 aborts the build with the
format warning below:
CC ramstage/cpu/x86/smm/smm_module_loader.o
src/cpu/x86/smm/smm_module_loader.c: In function 'smm_create_map':
src/cpu/x86/smm/smm_module_loader.c:146:19: error: format '%zx' expects argument of type 'size_t', but argument 3 has type 'uintptr_t' {aka 'long unsigned int'} [-Werror=format=]
146 | " smbase %zx entry %zx\n",
| ~~^
| |
| unsigned int
| %lx
147 | cpus[i].smbase, cpus[i].entry);
| ~~~~~~~~~~~~~~
| |
| uintptr_t {aka long unsigned int}
In coreboot `uintptr_t` is defined in `src/include/stdint.h`:
typedef unsigned long uintptr_t;
As `size_t` is defined as `long unsigned int` in i386-elf (32-bit), the
length modifier `z` matches there. With x86_64-elf/x86_64-linux-gnu
(64-bit) and `-m32` `size_t` is defined as `unsigned int` resulting in a
type mismatch. Normally, `PRIxPTR` would need to be used as a length
modifier, but as coreboot always defines `uintptr_t` to `unsigned long`
(and in `src/include/inttypes.h` also defines `PRIxPTR` as `"lx"`), use
the length modifier `l` to make the code more readable.
Found-by: x86_64-linux-gnu-gcc-10 (Debian 10.2.1-6) 10.2.1 20210110
Fixes: afb7a814 ("cpu/x86/smm: Introduce SMM module loader version 2")
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Change-Id: I32bff397c8a033fe34390e6c1a7dfe773707a4e8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54341
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Intel CBnT (and Boot Guard) makes the chain of trust TOCTOU safe by
setting up NEM (non eviction mode) in the ACM. The CBnT IBB (Initial
BootBlock) therefore should not disable caching.
Sidenote: the MSR macros are taken from the slimbootloader project.
TESTED: ocp/Deltalake boot with and without CBnT and also a broken
CBnT setup.
Change-Id: Id2031e4e406655e14198e45f137ba152f8b6f567
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54010
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
This removes the need to include this code separately on each
platform.
Change-Id: I3d848b1adca4921d7ffa2203348073f0a11d090e
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46380
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Fix booting issues on google/kahlee introduced by CB:51723.
Update use inital apic id in smm_stub.S to support xapic mode error.
Check more bits(LAPIC_BASE_MSR BIT10 and BIT11) for x2apic mode.
TEST=Boot to OS and check apicid, debug log for CPUIDs
cpuid_ebx(1), cpuid_ext(0xb, 0), cpuid_edx(0xb) etc
Signed-off-by: Wonkyu Kim <wonkyu.kim@intel.com>
Change-Id: Ia28f60a077182c3753f6ba9fbdd141f951d39b37
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52696
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This patch removes a call to console_init() and debug print message since
the code is not thread safe. This prevents system hangs (soft hangs)
while in SMM if user drops in a new SOC with more cores or another
socket or as a result of bad configuration. Console is already
initialized after the lock has been acquired so this does not affect any
other functionality.
Tested on DeltaLake mainboard with SMM enabled and 52 CPU threads.
Change-Id: I7e8af35d1cde78b327144b6a9da528ae7870e874
Signed-off-by: Rocky Phagura <rphagura@fb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52518
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Some platforms which have large amounts of RAM and also write-combining
regions may decide to drop the WC regions in favor of the default when
preserving MTRRs for the OS. From a data safety perspective, this is
safe to do, but if, say, the graphics framebuffer is the region that is
changed from WC to UC/WB, then the performance of writing to the
framebuffer will decrease dramatically.
Modern OSes typically use Page Attribute Tables (PAT) to determine the
cacheability on a page level and usually do not touch the MTRRs. Thus,
it is believed to be safe to stop reserving MTRRs for the OS, in
general; PentiumII is the exception here in that OSes that still
support that may still require MTRRs to be available. In any case, if
the OS wants to reprogram all of the MTRRs, it is of course still free
to do so (after consulting the e820 table).
BUG=b:185452338
TEST=Verify MTRR programming on a brya (where `sa_add_dram_resources`
was faked to think it had 32 GiB of DRAM installed) and variable MTRR
map includes a WC entry for the framebuffer (and all the RAM):
MTRR: default type WB/UC MTRR counts: 13/9.
MTRR: UC selected as default type.
MTRR: 0 base 0x0000000000000000 mask 0x00003fff80000000 type 6
MTRR: 1 base 0x0000000077000000 mask 0x00003fffff000000 type 0
MTRR: 2 base 0x0000000078000000 mask 0x00003ffff8000000 type 0
MTRR: 3 base 0x0000000090000000 mask 0x00003ffff0000000 type 1
MTRR: 4 base 0x0000000100000000 mask 0x00003fff00000000 type 6
MTRR: 5 base 0x0000000200000000 mask 0x00003ffe00000000 type 6
MTRR: 6 base 0x0000000400000000 mask 0x00003ffc00000000 type 6
MTRR: 7 base 0x0000000800000000 mask 0x00003fff80000000 type 6
MTRR: 8 base 0x000000087fc00000 mask 0x00003fffffc00000 type 0
ADL has 9 variable-range MTRRs, previously 8 of them were used, and
there was no separate entry for the framebuffer, thus leaving the
default MTRR in place of uncached.
Change-Id: I2ae2851248c95fd516627b101ebcb36ec59c29c3
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52522
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Coverity detects the control flow UNREACHABLE issue for the printk
usage. This change adds rc to keep the smm_module_setup_stub function
call and returns rc after printk usage.
Found-by: Coverity CID 1452602
TEST=None
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: Ie3b90a8197c3b84c5a1dbca8a9ef566bef35c9ab
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52574
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use the same stack location during relocation as for the permanent
handler.
When the number of CPUs is too large the stacks during relocation
don't fit inside the default SMRAM segment at 0x30000. Currently the
code would just let the CPU stack base grow downwards outside of the
default SMM segment which would corrupt lower memory if S3 is
implemented.
Also update the comment on smm_module_setup_stub().
Change-Id: I6a0a890e8b1c2408301564c22772032cfee4d296
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51186
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Implement x2apic mode as existing code only supports apic mode.
Use info from LAPIC_BASE_MSR (LAPIC_BASE_MSR_X2APIC_MODE) to check
if apic mode or x2apic mode and implement x2apic mode according to
x2apic specfication.
Reference:
https://software.intel.com/content/www/us/en/develop/download/intel-64-architecture-x2apic-specification.html
BUG=None
BRANCH=None
TEST=boot to OS and check apic mode
cat /proc/cpuinfo | grep "apicid"
ex) can see apicid bigger than 255
apicid : 256
apicid : 260
Signed-off-by: Wonkyu Kim <wonkyu.kim@intel.com>
Change-Id: I0bb729b0521fb9dc38b7981014755daeaf9ca817
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51723
Reviewed-by: Ravishankar Sarawadi <ravishankar.sarawadi@intel.com>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This fixes an issue introduced in
commit ad0116c032
cpu/x86/smm_loaderv2: Remove unused variables
It removed one variable that was needed to set the SMM start address
that is used to set the SMM stack location.
Change-Id: Iddf9f204db54f0d97a90bb423b65db2f7625217f
Signed-off-by: Marc Jones <marcjones@sysproconsulting.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51721
Reviewed-by: Jay Talbott <JayTalbott@sysproconsulting.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
