summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python
diff options
context:
space:
mode:
authorArd Biesheuvel <ardb@kernel.org>2026-09-25 09:51:39 +0200
committerBorislav Petkov (AMD) <bp@alien8.de>2026-09-28 15:07:42 -0700
commit0ffdb6c1ea44ddb40794b9c20a39b8fb30551875 (patch)
treed0aad5be74ed60a853c43acaf55a9494b555eb22 /tools/perf/scripts/python
parentb24bc9dec9c89d01ccb675a55cda6831dc048ce9 (diff)
downloadlinux-next-0ffdb6c1ea44ddb40794b9c20a39b8fb30551875.tar.gz
linux-next-0ffdb6c1ea44ddb40794b9c20a39b8fb30551875.zip
x86/tdx: Share tdx_panic() with the EFI stub
Move the implementation of tdx_panic() into the source file that is shared with the decompressor and the EFI stub. Use memcpy() and strnlen() instead of strtomem_pad(), as the latter does not exist in the early boot code. Avoid fortify instrumentation in the decompressor/EFI stub by defining __NO_FORTIFY before including tdx-shared.c Note that __tdx_hypercall() may call __tdx_hypercall_failed() if the hypercall returns with an error (while it should never return to begin with). __tdx_hypercall_failed() calls the decompressor's error() routine, which prints a message and then loops forever. When called from the EFI stub, this error() call may attempt to use port I/O to the default serial port rather than the TDX hypercalls which the decompressor uses normally to print diagnostics to the console, but this is fine: given that this situation only occurs after a catastrophic error, and a subsequent spurious return from tdx_panic(), whether error() uses port I/O or not is rather moot at that point, as long as it never returns. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org> Link: https://patch.msgid.link/20260925075137.44298-6-ardb@kernel.org
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions