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 0CA0FCCA479 for ; Wed, 29 Jun 2022 00:59:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7C25E6B0071; Tue, 28 Jun 2022 20:59:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 74BA08E0001; Tue, 28 Jun 2022 20:59:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 613186B0073; Tue, 28 Jun 2022 20:59:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 4F0286B0071 for ; Tue, 28 Jun 2022 20:59:19 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1F90A3332F for ; Wed, 29 Jun 2022 00:59:19 +0000 (UTC) X-FDA: 79629464838.16.46D93C4 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf02.hostedemail.com (Postfix) with ESMTP id 3AADA80039 for ; Wed, 29 Jun 2022 00:59:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1656464358; x=1688000358; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=PdXIIJIuvGiIGyuDJJCs/uSsICdNzkseyWhvo/anTLA=; b=jKmiyieu+DiNxVDYw8+AVfrGlHBHhFNPTLK1ZuLc4yhYHeEHzZ48B+fO LH0kdsRedLNasCn5hUdlnwJpme6a0zCXk+k7lbuORFUVfYoZYyceHhQ9M nEL0gyItZoYEg6UovGiKChmG0Tia9dAMTuioh53dT29MbFNry6yWjQZxD RjCLAjQOERxY2CxupShlJ7cbuFILaCJMjyOh0vF5aRfgEH4Tjaa7dgaeR OaW0LKT1Xmt7YzLG37nJqs5Doe4GSur6doQXnUJIKWzriO+H+QXmUcZI6 7MO39/Xdg0LiXyePeO5EpbIkS/b/aQ4V+mMudvNSGlWO0pbq/ImUCff71 w==; X-IronPort-AV: E=McAfee;i="6400,9594,10392"; a="279432800" X-IronPort-AV: E=Sophos;i="5.92,230,1650956400"; d="scan'208";a="279432800" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2022 17:59:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.92,230,1650956400"; d="scan'208";a="917394813" Received: from black.fi.intel.com ([10.237.72.28]) by fmsmga005.fm.intel.com with ESMTP; 28 Jun 2022 17:59:10 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 19836CE; Wed, 29 Jun 2022 03:59:15 +0300 (EEST) Date: Wed, 29 Jun 2022 03:59:15 +0300 From: "Kirill A. Shutemov" To: Dave Hansen Cc: "Eric W. Biederman" , Borislav Petkov , Andy Lutomirski , Sean Christopherson , Andrew Morton , Joerg Roedel , Ard Biesheuvel , 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, kexec@lists.infradead.org Subject: Re: [PATCHv7 11/14] x86: Disable kexec if system has unaccepted memory Message-ID: <20220629005915.gieli3dbjzvjbk5i@black.fi.intel.com> References: <20220614120231.48165-1-kirill.shutemov@linux.intel.com> <20220614120231.48165-12-kirill.shutemov@linux.intel.com> <6be29d38-5c93-7cc9-0de7-235d3f83773c@intel.com> <87a6a3aw50.fsf@email.froward.int.ebiederm.org> <20220624020005.txpxlsbjbebf6oq4@black.fi.intel.com> <20220628235105.z6ytdzxofrdkjti4@black.fi.intel.com> <88fe385c-fe40-d659-5081-7f3cdd9493e4@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <88fe385c-fe40-d659-5081-7f3cdd9493e4@intel.com> ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=jKmiyieu; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf02.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.93) smtp.mailfrom=kirill.shutemov@linux.intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656464358; a=rsa-sha256; cv=none; b=USNhZPRd7EVK5fHXTirsind3VPj2armOHaoNEyF8cZ4iKVMhkX+/ucmt0UaZPVq6SGAoiw iHk9g3GE08mXzH2Z+HjkQWHVJYrhqRvVBKihH0MSmCLoVNyc4jKS9awcBRQVXryy+r42o9 /oOv2rC75TAySqm7tQsOf3XS3oSWquc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656464358; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=+Txc62rqQt3JF/1hsDTzaq82h/mrrRCZGNka2KE7Hf0=; b=0t0dUtGEvJpwrlTlIzxIRgHOFSnChb9YeqjP8PLkbWzCmr7whit5saK3PjwbQC7uh+fgnW pHVJiHWVvgkkJ2KgeEgiwlLrEDm0HnwP0FT48WdZefNjWec1HhvwYOgLzxxVyUxsb3WdCY dckYkhqJb6QJOT/9NEi1BsKkspxMUf4= X-Stat-Signature: h7r8zwqseu15dsdtkkxhuak7kurni1if X-Rspamd-Server: rspam08 X-Rspam-User: X-Rspamd-Queue-Id: 3AADA80039 Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=jKmiyieu; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf02.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.93) smtp.mailfrom=kirill.shutemov@linux.intel.com X-HE-Tag: 1656464358-860735 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: On Tue, Jun 28, 2022 at 05:10:56PM -0700, Dave Hansen wrote: > On 6/28/22 16:51, Kirill A. Shutemov wrote: > > On Fri, Jun 24, 2022 at 05:00:05AM +0300, Kirill A. Shutemov wrote: > >>> If there is some deep and fundamental why this can not be supported > >>> then it probably makes sense to put some code in the arch_kexec_load > >>> hook that verifies that deep and fundamental reason is present. > ... > > + /* > > + * TODO: Information on memory acceptance status has to be communicated > > + * between kernel. > > + */ > > So, the deep and fundamental reason is... drum roll... you haven't > gotten around to implementing bitmap passing yet?!?!? I have the > feeling that wasn't what Eric was looking for. The deep fundamental reason is that everything cannot be implemented and upstreamed at once. -- Kirill A. Shutemov