[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87pmrjbmy9.fsf@disp2133>
Date: Mon, 01 Nov 2021 16:11:42 -0500
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Borislav Petkov <bp@...en8.de>
Cc: Joerg Roedel <joro@...tes.org>, x86@...nel.org,
kexec@...ts.infradead.org, Joerg Roedel <jroedel@...e.de>,
stable@...r.kernel.org, hpa@...or.com,
Andy Lutomirski <luto@...nel.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>,
Jiri Slaby <jslaby@...e.cz>,
Dan Williams <dan.j.williams@...el.com>,
Tom Lendacky <thomas.lendacky@....com>,
Juergen Gross <jgross@...e.com>,
Kees Cook <keescook@...omium.org>,
David Rientjes <rientjes@...gle.com>,
Cfir Cohen <cfir@...gle.com>,
Erdem Aktas <erdemaktas@...gle.com>,
Masami Hiramatsu <mhiramat@...nel.org>,
Mike Stunes <mstunes@...are.com>,
Sean Christopherson <seanjc@...gle.com>,
Martin Radev <martin.b.radev@...il.com>,
Arvind Sankar <nivedita@...m.mit.edu>,
linux-coco@...ts.linux.dev, linux-kernel@...r.kernel.org,
kvm@...r.kernel.org, virtualization@...ts.linux-foundation.org
Subject: Re: [PATCH v2 01/12] kexec: Allow architecture code to opt-out at runtime
Borislav Petkov <bp@...en8.de> writes:
> On Mon, Sep 13, 2021 at 05:55:52PM +0200, Joerg Roedel wrote:
>> From: Joerg Roedel <jroedel@...e.de>
>>
>> Allow a runtime opt-out of kexec support for architecture code in case
>> the kernel is running in an environment where kexec is not properly
>> supported yet.
>>
>> This will be used on x86 when the kernel is running as an SEV-ES
>> guest. SEV-ES guests need special handling for kexec to hand over all
>> CPUs to the new kernel. This requires special hypervisor support and
>> handling code in the guest which is not yet implemented.
>>
>> Cc: stable@...r.kernel.org # v5.10+
>> Signed-off-by: Joerg Roedel <jroedel@...e.de>
>> ---
>> include/linux/kexec.h | 1 +
>> kernel/kexec.c | 14 ++++++++++++++
>> kernel/kexec_file.c | 9 +++++++++
>> 3 files changed, 24 insertions(+)
>
> I guess I can take this through the tip tree along with the next one.
I seem to remember the consensus when this was reviewed that it was
unnecessary and there is already support for doing something like
this at a more fine grained level so we don't need a new kexec hook.
Eric
Powered by blists - more mailing lists