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 286ABC433EF for ; Fri, 8 Apr 2022 18:08:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4C6616B0074; Fri, 8 Apr 2022 14:08:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 475B76B0075; Fri, 8 Apr 2022 14:08:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 33E256B0078; Fri, 8 Apr 2022 14:08:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0249.hostedemail.com [216.40.44.249]) by kanga.kvack.org (Postfix) with ESMTP id 283EC6B0074 for ; Fri, 8 Apr 2022 14:08:49 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id DE742183A6EC9 for ; Fri, 8 Apr 2022 18:08:48 +0000 (UTC) X-FDA: 79334497536.23.432CF27 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by imf26.hostedemail.com (Postfix) with ESMTP id E427F14000A for ; Fri, 8 Apr 2022 18:08:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1649441328; x=1680977328; h=message-id:date:mime-version:to:cc:references:from: subject:in-reply-to:content-transfer-encoding; bh=lnjfjM6We5ORXBOaO26qklSGxKpKgnuGsjWUu4xUFlQ=; b=n0W3Rd5C65QNZSQY+e3WpW6b6wzwg2rxK1j7ak2+V1LFQHD2k1rRC0Lo iuR7TebF19qruQ00T1rjKYGJvDp+1Mvje+ButolbKAqHftRgnnHdYHMNU cJRN/CaQsdW6+1jluuG1duYWVIoexPKhrPJN3GScqAHwDsj5LKS8eQM3p 0dRHb/zT6Hukdp3JIpl9bWTxJtRAQPtl8y1ecv7+I2S54AFnb6eK+qjMq MHPqMgTt+ixKnGXgI4idOCrwRHwik5bDqmxMZky9w1l6iJ5JpccfrubY8 PIRIrGadlpCkIRm+8yJVX78i2kjdhJ3xm6FnXvj1K0+FZ7CTc+V8Id5L9 g==; X-IronPort-AV: E=McAfee;i="6400,9594,10311"; a="348091528" X-IronPort-AV: E=Sophos;i="5.90,245,1643702400"; d="scan'208";a="348091528" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Apr 2022 11:08:46 -0700 X-IronPort-AV: E=Sophos;i="5.90,245,1643702400"; d="scan'208";a="525473383" Received: from tsungtae-mobl.amr.corp.intel.com (HELO [10.134.43.198]) ([10.134.43.198]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Apr 2022 11:08:45 -0700 Message-ID: <1ac804b3-eaaf-e87d-2fb5-30125c81ae28@intel.com> Date: Fri, 8 Apr 2022 11:08:48 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 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 , Brijesh Singh , Mike Rapoport , David Hildenbrand , x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, Mike Rapoport References: <20220405234343.74045-1-kirill.shutemov@linux.intel.com> <20220405234343.74045-6-kirill.shutemov@linux.intel.com> From: Dave Hansen Subject: Re: [PATCHv4 5/8] x86/mm: Reserve unaccepted memory bitmap In-Reply-To: <20220405234343.74045-6-kirill.shutemov@linux.intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=n0W3Rd5C; spf=none (imf26.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 192.55.52.43) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: E427F14000A X-Stat-Signature: ouf5sfj4jbpc1h6y7s6rsest48fe551g X-HE-Tag: 1649441327-185320 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 4/5/22 16:43, Kirill A. Shutemov wrote: > A given page of memory can only be accepted once. The kernel has a need > to accept memory both in the early decompression stage and during normal > runtime. > > A bitmap used to communicate the acceptance state of each page between the > decompression stage and normal runtime. This eliminates the possibility of > attempting to double-accept a page. ... which is fatal, right? Could you include that an also the rationale for why it is fatal? > The bitmap is allocated in EFI stub, decompression stage updates the state > of pages used for the kernel and initrd and hands the bitmap over to the > main kernel image via boot_params. This is really good info. Could we maybe expand it a bit? There are several steps in the bitmap's lifecycle: 1. Bitmap is allocated in the EFI stub 2. The kernel decompression code locates it, accepts some pages before decompression and marks them in the bitmap. 3. Decompression code points to the bitmap via a boot_param 4. Main kernel locates bitmap via the boot_param and uses it to guide runtime acceptance decisions. > In the runtime kernel, reserve the bitmap's memory to ensure nothing > overwrites it. > > Signed-off-by: Kirill A. Shutemov > Acked-by: Mike Rapoport > --- > arch/x86/kernel/e820.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c > index f267205f2d5a..22d1fe48dcba 100644 > --- a/arch/x86/kernel/e820.c > +++ b/arch/x86/kernel/e820.c > @@ -1316,6 +1316,16 @@ void __init e820__memblock_setup(void) > int i; > u64 end; > > + /* Mark unaccepted memory bitmap reserved */ > + if (boot_params.unaccepted_memory) { > + unsigned long size; > + > + /* One bit per 2MB */ > + size = DIV_ROUND_UP(e820__end_of_ram_pfn() * PAGE_SIZE, > + PMD_SIZE * BITS_PER_BYTE); > + memblock_reserve(boot_params.unaccepted_memory, size); > + } One oddity here: The size is implied by the e820's contents. Did you mention somewhere that unaccepted memory is considered E820_TYPE_RAM? It *has* to be in order for e820__end_of_ram_pfn() to work, right?