Thread (183 messages) 183 messages, 11 authors, 2022-01-29

Re: [PATCH v8 11/40] x86/sev: Register GHCB memory when SEV-SNP is active

From: Brijesh Singh <hidden>
Date: 2021-12-22 15:17:08
Also in: kvm, linux-efi, linux-mm, lkml, platform-driver-x86


On 12/22/21 7:16 AM, Borislav Petkov wrote:
On Fri, Dec 10, 2021 at 09:43:03AM -0600, Brijesh Singh wrote:
quoted
@@ -652,7 +652,7 @@ static enum es_result vc_handle_msr(struct ghcb *ghcb, struct es_em_ctxt *ctxt)
   * This function runs on the first #VC exception after the kernel
   * switched to virtual addresses.
   */
-static bool __init sev_es_setup_ghcb(void)
+static bool __init setup_ghcb(void)
  {
  	/* First make sure the hypervisor talks a supported protocol. */
  	if (!sev_es_negotiate_protocol())
Ok, let me stare at this for a while:

This gets called by handle_vc_boot_ghcb() which gets set at build time:

arch/x86/kernel/head_64.S:372:SYM_DATA(initial_vc_handler,      .quad handle_vc_boot_ghcb)

initial_vc_handler() gets called by vc_boot_ghcb() which gets set in

early_setup_idt()

and that function already does sev_snp_register_ghcb().

So why don't you concentrate the work setup_ghcb() does before the first
#VC and call it in early_setup_idt(), before the IDT is set?

And then you get rid of yet another setup-at-first-use case?
I was following the existing SEV-ES implementation in which GHCB is 
setup on first #VC. But recently you recommended to move the setup 
outside of the VC handler for the decompression path and I was going to 
do the same for the kernel proper. I have tried moving the GHCB setup 
outside and it seems to be working okay with me (a limited testing so 
far). I will check Jorge to see if there was any reason for doing the 
GHCB setup inside the VC for the SEV-ES case.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help