[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0c990c7d-4df9-45c1-8c03-980d9842b963@intel.com>
Date: Thu, 1 Feb 2024 22:22:18 +0800
From: "Huang, Kai" <kai.huang@...el.com>
To: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>, Dave Hansen
<dave.hansen@...el.com>
CC: <linux-kernel@...r.kernel.org>, <x86@...nel.org>, <tglx@...utronix.de>,
<bp@...en8.de>, <mingo@...hat.com>, <hpa@...or.com>, <luto@...nel.org>,
<peterz@...radead.org>, <thomas.lendacky@....com>, <chao.gao@...el.com>,
<bhe@...hat.com>, <nik.borisov@...e.com>, <pbonzini@...hat.com>
Subject: Re: [PATCH 3/4] x86/kexec(): Reset TDX private memory on platforms
with TDX erratum
On 1/02/2024 6:03 am, Kirill A. Shutemov wrote:
> On Wed, Jan 31, 2024 at 01:21:39PM -0800, Dave Hansen wrote:
>>> #ifdef CONFIG_KEXEC_JUMP
>>> if (image->preserve_context)
>>> save_processor_state();
>>> + else
>>> + tdx_reset_memory();
>>> +#else
>>> + tdx_reset_memory();
>>> #endif
>>
>> Wow, that's awfully hard to read. I really wish folks' gag reflex would
>> kick in when they see stuff like this to get them to spend an additional
>> 15 seconds to turn this into:
>>
>> if (IS_ENABLED(CONFIG_KEXEC_JUMP) && image->preserve_context)
>> save_processor_state();
>> else
>> tdx_reset_memory();
>
> save_processor_state() is declared under CONFIG_PM_SLEEP, so I guess your
> variant might break build in some cases without updated suspend.h.
I tried. If I turn off both SUSPEND and HIBERNATION in the Kconfig I
got build error:
arch/x86/kernel/machine_kexec_64.c:325:17: error: implicit declaration
of function ‘save_processor_state’ [-Werror=implicit-function-declaration]
325 | save_processor_state();
| ^~~~~~~~~~~~~~~~~~~~
Powered by blists - more mailing lists