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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 99A13C43334 for ; Thu, 23 Jun 2022 17:24:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EDA8E8E0169; Thu, 23 Jun 2022 13:24:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EB08F8E0144; Thu, 23 Jun 2022 13:24:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D78DC8E0169; Thu, 23 Jun 2022 13:24:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id C79478E0144 for ; Thu, 23 Jun 2022 13:24:28 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 8C9532EA76 for ; Thu, 23 Jun 2022 17:24:28 +0000 (UTC) X-FDA: 79610174616.02.4EC0037 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by imf09.hostedemail.com (Postfix) with ESMTP id E02DC1400BD for ; Thu, 23 Jun 2022 17:24:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1656005067; x=1687541067; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=HyD7sZmGzSIHx03CaYUHtjWHrLaftO9PYHM6NFaUHG0=; b=UYcBB/2G2YKApuNgtAi76sCDjPFxlrpqZm9Bh6Cgy1NhT6h6i2PWgBPn jWjwyHgRRWSy6iVwtRJOxxR7lZ65itb1JNsL4g28UByYSjScl+D51c1NM khVM4MblgyEywGAhwed6ztYaS3xVjN12iBsw8sWnRTu+5A4kMDT5WDzTB pNmvw4bkapRrv7xBAZZZxyF445koTSGvPfdQ5z02HjPJ3s3ZRv9DZBp68 pqTpb5FyUZYmRoxWQyKbKbL87jNgKS39M5akmUhr9Ae55lZnwdTxN6BVJ koNtFuar+4+sv+PHY7B8vqZysumgGCDtMlotpnz4S0hGRKewIBOdjRbgU A==; X-IronPort-AV: E=McAfee;i="6400,9594,10387"; a="279552926" X-IronPort-AV: E=Sophos;i="5.92,216,1650956400"; d="scan'208";a="279552926" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jun 2022 10:24:26 -0700 X-IronPort-AV: E=Sophos;i="5.92,216,1650956400"; d="scan'208";a="563531696" Received: from ckeane-mobl1.amr.corp.intel.com (HELO [10.209.81.98]) ([10.209.81.98]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jun 2022 10:24:25 -0700 Message-ID: <6be29d38-5c93-7cc9-0de7-235d3f83773c@intel.com> Date: Thu, 23 Jun 2022 10:23:59 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCHv7 11/14] x86: Disable kexec if system has unaccepted memory Content-Language: en-US To: "Kirill A. Shutemov" , Borislav Petkov , Andy Lutomirski , Sean Christopherson , Andrew Morton , Joerg Roedel , Ard Biesheuvel Cc: Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Varad Gautam , Dario Faggioli , Mike Rapoport , David Hildenbrand , marcelo.cerri@canonical.com, tim.gardner@canonical.com, khalid.elmously@canonical.com, philip.cox@canonical.com, x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, Eric Biederman , kexec@lists.infradead.org References: <20220614120231.48165-1-kirill.shutemov@linux.intel.com> <20220614120231.48165-12-kirill.shutemov@linux.intel.com> From: Dave Hansen In-Reply-To: <20220614120231.48165-12-kirill.shutemov@linux.intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656005068; a=rsa-sha256; cv=none; b=1x2byf19DN0nsm6oBTpnv5CIz4uxLiysXQGzvvdYDdbSBgBCIykqg63sA8ZuB3aYrZEKCP 30s6rtF4o5oC+OWrPeANMlyyzl2gDeCcPm8W55zJjvsh0L89iNQ71CASJw1M8z4Na+g/SA LS3PtYbNvgiE3/rVFDRKpGYwkvQzgKM= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="UYcBB/2G"; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf09.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 192.55.52.120) smtp.mailfrom=dave.hansen@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656005068; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=XMO8PGOEOxzbbgXIQj/FQftvwqOA5Zaw6uw/HEfy5IQ=; b=F+wLx/enUW4VS0FyzhjUsO4amES5x4KBRCNkf/tiB7j33hIqIh3tzMEKBrhK1JAZ53I3WF la0gz83ELxhmPnNcY05WPfOc7aHIzsYo0O/EKjRix9R6ezeBl7iP7XVxZageo09xJji2/2 xYpdmfoUM/vwAAXI3wcdjtJeqnLqKdg= X-Stat-Signature: js9ziysgyf1ahqth8xhq7s37qqh6xczk X-Rspamd-Queue-Id: E02DC1400BD Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="UYcBB/2G"; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf09.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 192.55.52.120) smtp.mailfrom=dave.hansen@intel.com X-Rspamd-Server: rspam10 X-Rspam-User: X-HE-Tag: 1656005067-260371 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: ... adding kexec folks On 6/14/22 05:02, Kirill A. Shutemov wrote: > On kexec, the target kernel has to know what memory has been accepted. > Information in EFI map is out of date and cannot be used. > > boot_params.unaccepted_memory can be used to pass the bitmap between two > kernels on kexec, but the use-case is not yet implemented. > > Disable kexec on machines with unaccepted memory for now. ... > +static int __init unaccepted_init(void) > +{ > + if (!boot_params.unaccepted_memory) > + return 0; > + > +#ifdef CONFIG_KEXEC_CORE > + /* > + * TODO: Information on memory acceptance status has to be communicated > + * between kernel. > + */ > + pr_warn("Disable kexec: not yet supported on systems with unaccepted memory\n"); > + kexec_load_disabled = 1; > +#endif This looks to be the *only* in-kernel user tweaking kexec_load_disabled. It doesn't feel great to just be disabling kexec like this. Why not just fix it properly? What do the kexec folks think?