[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <l3uo3n3li27czehll2wz34xxkcv5j2vcshgp5a6w7u4h4aidpu@4oe2cwye2e6z>
Date: Thu, 1 Feb 2024 00:03:59 +0200
From: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
To: Dave Hansen <dave.hansen@...el.com>
Cc: "Huang, Kai" <kai.huang@...el.com>, 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 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.
--
Kiryl Shutsemau / Kirill A. Shutemov
Powered by blists - more mailing lists