[lkml]   [2021]   [Dec]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v8 11/40] x86/sev: Register GHCB memory when SEV-SNP is active

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.

 \ /
  Last update: 2021-12-22 16:17    [W:0.085 / U:13.528 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site