summaryrefslogtreecommitdiffstats
path: root/arch/x86/boot
diff options
context:
space:
mode:
authorTom Lendacky <thomas.lendacky@amd.com>2024-06-05 10:18:46 -0500
committerBorislav Petkov (AMD) <bp@alien8.de>2024-06-11 07:22:46 +0200
commit34ff659017359116dd58b1e008d99d21b96b3569 (patch)
treee091392d2f03240e0efdee9c22b6a2dec884a5e7 /arch/x86/boot
parent878e70dbd26e234e6e6941dac3a233af6f632184 (diff)
downloadlinux-stable-34ff659017359116dd58b1e008d99d21b96b3569.tar.gz
linux-stable-34ff659017359116dd58b1e008d99d21b96b3569.tar.bz2
linux-stable-34ff659017359116dd58b1e008d99d21b96b3569.zip
x86/sev: Use kernel provided SVSM Calling Areas
The SVSM Calling Area (CA) is used to communicate between Linux and the SVSM. Since the firmware supplied CA for the BSP is likely to be in reserved memory, switch off that CA to a kernel provided CA so that access and use of the CA is available during boot. The CA switch is done using the SVSM core protocol SVSM_CORE_REMAP_CA call. An SVSM call is executed by filling out the SVSM CA and setting the proper register state as documented by the SVSM protocol. The SVSM is invoked by by requesting the hypervisor to run VMPL0. Once it is safe to allocate/reserve memory, allocate a CA for each CPU. After allocating the new CAs, the BSP will switch from the boot CA to the per-CPU CA. The CA for an AP is identified to the SVSM when creating the VMSA in preparation for booting the AP. [ bp: Heavily simplify svsm_issue_call() asm, other touchups. ] Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/fa8021130bcc3bcf14d722a25548cb0cdf325456.1717600736.git.thomas.lendacky@amd.com
Diffstat (limited to 'arch/x86/boot')
0 files changed, 0 insertions, 0 deletions