From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 04AC1C433F5 for ; Tue, 2 Nov 2021 18:17:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E338B61050 for ; Tue, 2 Nov 2021 18:17:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235059AbhKBSUc (ORCPT ); Tue, 2 Nov 2021 14:20:32 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:56482 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235044AbhKBSU2 (ORCPT ); Tue, 2 Nov 2021 14:20:28 -0400 Received: from in01.mta.xmission.com ([166.70.13.51]:49648) by out02.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1mhyLz-00AIEV-OE; Tue, 02 Nov 2021 12:17:47 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95]:37066 helo=email.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1mhyLo-006iWW-Cc; Tue, 02 Nov 2021 12:17:42 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Joerg Roedel Cc: Borislav Petkov , Joerg Roedel , x86@kernel.org, kexec@lists.infradead.org, stable@vger.kernel.org, hpa@zytor.com, Andy Lutomirski , Dave Hansen , Peter Zijlstra , Jiri Slaby , Dan Williams , Tom Lendacky , Juergen Gross , Kees Cook , David Rientjes , Cfir Cohen , Erdem Aktas , Masami Hiramatsu , Mike Stunes , Sean Christopherson , Martin Radev , Arvind Sankar , linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org References: <20210913155603.28383-1-joro@8bytes.org> <20210913155603.28383-2-joro@8bytes.org> <87pmrjbmy9.fsf@disp2133> Date: Tue, 02 Nov 2021 13:17:26 -0500 In-Reply-To: (Joerg Roedel's message of "Tue, 2 Nov 2021 18:00:21 +0100") Message-ID: <87k0hq777t.fsf@disp2133> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1mhyLo-006iWW-Cc;;;mid=<87k0hq777t.fsf@disp2133>;;;hst=in01.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19ZFP83sW/GDuonSMarVsicvRtUXK4AeQY= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH v2 01/12] kexec: Allow architecture code to opt-out at runtime X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Joerg Roedel writes: > Hi again, > > On Mon, Nov 01, 2021 at 04:11:42PM -0500, Eric W. Biederman wrote: >> 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. > > Forgot to state to problem again which these patches solve: > > Currently a Linux kernel running as an SEV-ES guest has no way to > successfully kexec into a new kernel. The normal SIPI sequence to reset > the non-boot VCPUs does not work in SEV-ES guests and special code is > needed in Linux to safely hand over the VCPUs from one kernel to the > next. What happens currently is that the kexec'ed kernel will just hang. > > The code which implements the VCPU hand-over is also included in this > patch-set, but it requires a certain level of Hypervisor support which > is not available everywhere. > > To make it clear to the user that kexec will not work in their > environment, it is best to disable the respected syscalls. This is what > the hook is needed for. Note this is environmental. This is the equivalent of a driver for a device without some feature. The kernel already has machine_kexec_prepare, which is perfectly capable of detecting this is a problem and causing kexec_load to fail. Which is all that is required. We don't need a new hook and a new code path to test for one architecture. So when we can reliably cause the system call to fail with a specific error code I don't think it makes sense to make clutter up generic code because of one architecture's design mistakes. My honest preference would be to go farther and have a firmware/hypervisor/platform independent rendezvous for the cpus so we don't have to worry about what bugs the code under has implemented for this special case. Because frankly there when there are layers of software if a bug can slip through it always seems to and causes problems. But definitely there is no reason to add another generic hook when the existing hook is quite good enough. Eric