[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3f419ba5-7b95-45f0-adb3-d7397949c14e@intel.com>
Date: Tue, 10 Sep 2024 14:42:20 +1200
From: "Huang, Kai" <kai.huang@...el.com>
To: "Kaplan, David" <David.Kaplan@....com>, "Hansen, Dave"
<dave.hansen@...el.com>, "bp@...en8.de" <bp@...en8.de>, "tglx@...utronix.de"
<tglx@...utronix.de>, "peterz@...radead.org" <peterz@...radead.org>,
"mingo@...hat.com" <mingo@...hat.com>, "hpa@...or.com" <hpa@...or.com>,
"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>
CC: "x86@...nel.org" <x86@...nel.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "pbonzini@...hat.com" <pbonzini@...hat.com>,
"seanjc@...gle.com" <seanjc@...gle.com>, "Williams, Dan J"
<dan.j.williams@...el.com>, "Lendacky, Thomas" <Thomas.Lendacky@....com>,
"Edgecombe, Rick P" <rick.p.edgecombe@...el.com>, "Yamahata, Isaku"
<isaku.yamahata@...el.com>, "Kalra, Ashish" <Ashish.Kalra@....com>,
"bhe@...hat.com" <bhe@...hat.com>, "nik.borisov@...e.com"
<nik.borisov@...e.com>, "sagis@...gle.com" <sagis@...gle.com>, Dave Young
<dyoung@...hat.com>
Subject: Re: [PATCH v6 2/5] x86/kexec: do unconditional WBINVD for bare-metal
in relocate_kernel()
>> --- a/arch/x86/kernel/machine_kexec_64.c
>> +++ b/arch/x86/kernel/machine_kexec_64.c
>> @@ -322,16 +322,9 @@ void machine_kexec_cleanup(struct kimage *image)
>> void machine_kexec(struct kimage *image) {
>> unsigned long page_list[PAGES_NR];
>> - unsigned int host_mem_enc_active;
>> int save_ftrace_enabled;
>> void *control_page;
>>
>> - /*
>> - * This must be done before load_segments() since if call depth tracking
>> - * is used then GS must be valid to make any function calls.
>> - */
>> - host_mem_enc_active =
>> cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT);
>> -
>
> Functionally the patch looks fine. I would suggest keeping some form of this comment though, because the limitation about not being able to make function calls after load_segments() is arguably non-obvious and this comment served as a warning for future modifications in this area.
Yeah this makes sense. Thanks.
I think we can add some text to the existing comment of load_segments()
to call out this. Allow me to dig into more about call depth tracking
to understand it better -- relocate_kernel() after load_segments() seems
to be a real function call and I want to know how does it interact with
call depth tracking.
Powered by blists - more mailing lists