Enable long mode in SMM handler.
x86_32 isn't affected by this change.
* Enter long mode
* Add 64bit entry to GDT
* Use x86_64 SysV ABI calling conventions for C code entry
* Change smm_module_params' cpu to size_t as 'push' is native integer
* Drop to protected mode after c handler
NOTE: This commit does NOT introduce a new security model. It uses the
same page tables as the remaining firmware does.
This can be a security risk if someone is able to manipulate the
page tables stored in ROM at runtime. USE FOR TESTING ONLY!
Tested on Lenovo T410 with additional x86_64 patches.
Change-Id: I26300492e4be62ddd5d80525022c758a019d63a1
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37392
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Eugene Myers <cedarhouse1@comcast.net>
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>
The Kconfig lint tool checks for cases of the code using BOOL type
Kconfig options directly instead of with CONFIG() and will print out
warnings about it. It gets confused by these references in comments
and strings. To fix it so that it can find the real issues, just
update these as we would with real issues.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I5c37f0ee103721c97483d07a368c0b813e3f25c0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43824
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
It's not related to spinlocks and the actual implementation
was also guarded by CONFIG(SMP).
With a single call-site in x86-specific code, empty stubs
for other arch are currently not necessary.
Also drop an unused included on a nearby line.
Change-Id: I00439e9c1d10c943ab5e404f5d687d316768fa16
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43808
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The "normalized" boot mode is only used in a single place, so there's no
need to use a variable. Also, reword the associated comment, which seems
to be unnecessarily vague: the hardcoded assumptions are inside the MRC.
Change-Id: I260d10f231f5de765d2675416d7047717d391d8f
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43092
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tristan Corrick <tristan@corrick.kiwi>
Enable long mode in SMM handler.
x86_32 isn't affected by this change.
As the rsm instruction used to leave SMM doesn't restore MSR registers,
drop back to protected mode after running the smi_handler and restore
IA32_EFER MSR (which enables long mode support) to previous value.
NOTE: This commit does NOT introduce a new security model. It uses the
same page tables as the remaining firmware does.
This can be a security risk if someone is able to manipulate the
page tables stored in ROM at runtime. USE FOR TESTING ONLY!
Tested on Qemu Q35.
Change-Id: I8bba4af4688c723fc079ae905dac95f57ea956f8
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35681
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The assumption up to this point was that if the system had an x86
processor, verstage would be running on the x86 processor. With running
verstage on the PSP, that assumption no longer holds true, so exclude
pieces of code that cause problems for verstage on the PSP.
This change will add these files to verstage only if the verstage
architecture is X86 - either 32 or 64 bit.
BUG=b:158124527
TEST=Build and boot on Trembyle
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I797b67394825172bd44ad1ee693a0c509289486b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42062
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Eric Peers <epeers@google.com>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Most LAPIC registers are 32bit, and thus the use of long is valid on
x86_32, however it doesn't work on x86_64.
* Don't use long as it is 64bit on x86_64, which breaks interrupts
in QEMU and thus SeaBIOS wouldn't time out the boot menu
* Get rid of unused defines
* Get rid of unused atomic xchg code
Tested on QEMU Q35 with x86_64 enabled: Interrupts work again.
Tested on QEMU Q35 with x86_32 enabled: Interrupts are still working.
Tested on Lenovo T410 with x86_64 enabled.
Change-Id: Iaed1ad956d090625c7bb5cd9cf55cbae16dd82bd
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36777
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When Linux is booted, the kernel reports
"do_IRQ: 1.55 No irq handler for vector"
So far it comes with payloads SeaBIOS and depthcharge, not with
Grub. We assume Grub does something to avoid this problem.
AMD bug tracker system (JIRA PLAT-21393) says the APs can not be set
EXTINT delivery mode.
In Intel 64 and IA-32 Architectures Software Developer’s Manual volume
3A, see chapter 10.5.1 Local Vector Table, it says:
"The APIC architecture supports only one ExtINT source in a system,
usually contained in the compatibility bridge. Only one processor in the
system should have an LVT entry configured to use the ExtINT delivery
mode."
Tested on mandolin (Picasso) board, the error in dmesg is gone.
The bug 153677727 has two parts.
1. Soft lockup
2. do_IRQ 1.55.
The soft lockup issued has been fixed by
https://review.coreboot.org/c/coreboot/+/41128
BUG=b:153677727
TEST=mandolin
Change-Id: I2956dcaad87cc1466deeca703748de33390b7603
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42219
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
A looong time ago when cache_as_ram.S was built into romstage,
the stage was also linked twice. First at a fixed low address
and then again relocated at the final execute-in-place address.
Change-Id: Ic624feef6794f2c24e38459a45583d84fc07a484
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42347
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
When adding XIP stages on x86, the -P parameter was used to
pass a page size that covers the entire file to add. The same
can now be achieved with --pow2page and we no longer need to
define a static Konfig for the purpose.
TEST: Build asus/p2b and lenovo/x60 with "--pow2page -v -v" and
inspect the generated make.log files. The effective pagesize is
reduced from 64kB to 16kB for asus/p2b giving more freedom
for the stage placement inside CBFS. Pagesize remained at 64kB
for lenovo/x60.
Change-Id: I5891fa2c2bb2d44077f745619162b143d083a6d1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41820
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Keith Hui <buurin@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change defines a Kconfig variable MEMLAYOUT_LD_FILE which allows
SoC/mainboard to provide a linker file for the platform. x86 already
provides a default memlayout.ld under src/arch/x86. With this new
Kconfig variable, it is possible for the SoC/mainboard code for x86 to
provide a custom linker file as well.
Makefile.inc is updated for all architectures to use this new Kconfig
variable instead of assuming memlayout.ld files under a certain
path. All non-x86 boards used memlayout.ld under mainboard
directory. However, a lot of these boards were simply including the
memlayout from SoC. So, this change also updates these mainboards and
SoCs to define the Kconfig as required.
BUG=b:155322763
TEST=Verified that abuild with --timeless option results in the same
coreboot.rom image for all boards.
Change-Id: I6a7f96643ed0519c93967ea2c3bcd881a5d6a4d6
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42292
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According to the comments of
https://review.coreboot.org/c/coreboot/+/41719
, which is about Microcode patch for amd/picasso.
Change the code with the same way.
The changes include:
1. combine the microcode_xxx.c and update_microcode.c
into one source.
2. Redefine the microcode updating function to eliminate
the parameter. Get the revision ID in the black box.
Reduce the depth of function calls.
3. Get the revision ID by bitwise calculation instead of
lookup table.
4. Reduce the confusing type casts.
5. Squash some lines.
We do not change the way it used to be. The code assume
only one microcode is integrated in CBFS. If needed in future,
41719 is the example of integrating multiple binaries.
And, 41719 depends on the definition in this patch.
Change-Id: I8b0da99db0d3189058f75e199f05492c4e6c5881
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42094
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
