Messages in this thread |  | | Subject | Re: [PATCH v8 11/40] x86/sev: Register GHCB memory when SEV-SNP is active | From | Brijesh Singh <> | Date | Wed, 22 Dec 2021 09:16:54 -0600 |
| |
On 12/22/21 7:16 AM, Borislav Petkov wrote: > On Fri, Dec 10, 2021 at 09:43:03AM -0600, Brijesh Singh wrote: >> @@ -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.
|  |