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 DA54DC433F5 for ; Sun, 30 Jan 2022 08:40:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 43F776B0072; Sun, 30 Jan 2022 03:40:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3EEDF6B0073; Sun, 30 Jan 2022 03:40:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 304BD6B0074; Sun, 30 Jan 2022 03:40:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0077.hostedemail.com [216.40.44.77]) by kanga.kvack.org (Postfix) with ESMTP id 21EDE6B0072 for ; Sun, 30 Jan 2022 03:40:09 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id C9E7398785 for ; Sun, 30 Jan 2022 08:40:08 +0000 (UTC) X-FDA: 79086306096.24.0FB0105 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf18.hostedemail.com (Postfix) with ESMTP id 524591C0002 for ; Sun, 30 Jan 2022 08:40:08 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 7E362B8285E; Sun, 30 Jan 2022 08:40:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AE8C3C340E4; Sun, 30 Jan 2022 08:39:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643532005; bh=mMLK/fB0QMJ3MNzMIxpx0yDzHoVKivXV5668cDA+aKQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bWG5SwoxI7Lf6y7IDW7qjyM/D+k3pdtHe7MbUgpd9ERfe11UZABkDQInZxHmNpvD0 /nwRiVpcr9IjnencMEaf52ZBhwYE6Lyh2BuBzT/lWeMH9Od0RIBbuI0IWLMSY7HdKr hMQJPOJrvFFPdxYTPO5yv8PzM5dmN2eQgdOf88rSqBS63mnC68I3xBoHd0SjbjZWmd pv6DGaXc8zPCDxJABgEUKKSt8Giv59OqfWGbsmkwrs6/ginQl3brxAS03lls3T4uT3 PydWZiUMzjueAS/pEs8SyaYrTw7R8TBj3B4chZjdl+sRoS03HmWdb+AajmyoZk0NVq 6j7AKTMxbH1xg== Date: Sun, 30 Jan 2022 10:39:52 +0200 From: Mike Rapoport To: "Kirill A. Shutemov" Cc: 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 , Dave Hansen , Brijesh Singh , David Hildenbrand , x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCHv3 5/7] x86/mm: Reserve unaccepted memory bitmap Message-ID: References: <20220128205906.27503-1-kirill.shutemov@linux.intel.com> <20220128205906.27503-6-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220128205906.27503-6-kirill.shutemov@linux.intel.com> Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=bWG5Swox; spf=pass (imf18.hostedemail.com: domain of rppt@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspam-User: nil X-Rspamd-Queue-Id: 524591C0002 X-Stat-Signature: tniws8uj8jwyfxquucrbnresuaoau8dz X-Rspamd-Server: rspam12 X-HE-Tag: 1643532008-564210 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 Fri, Jan 28, 2022 at 11:59:04PM +0300, 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. > > Use a bitmap 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. > > Allocate the bitmap during decompression stage and hand it over to the > main kernel image via boot_params. These two paragraphs imply that you add bitmap allocation to the decompression in this patch. Besides, AFAIU the actual allocation happens before the decompression in EFI stub. How about slightly rephrasing: ---8<--- 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. 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. ---8<--- > 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 bc0657f0deed..3905bd1ca41d 100644 > --- a/arch/x86/kernel/e820.c > +++ b/arch/x86/kernel/e820.c > @@ -1297,6 +1297,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); > + } > + > /* > * The bootstrap memblock region count maximum is 128 entries > * (INIT_MEMBLOCK_REGIONS), but EFI might pass us more E820 entries > -- > 2.34.1 > -- Sincerely yours, Mike.