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 8B86FCCA473 for ; Wed, 1 Jun 2022 14:44:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 139248D0020; Wed, 1 Jun 2022 10:44:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0C4DE8D001C; Wed, 1 Jun 2022 10:44:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ECC3B8D0020; Wed, 1 Jun 2022 10:44:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id D95958D001C for ; Wed, 1 Jun 2022 10:44:57 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 5F2A0120AF6 for ; Wed, 1 Jun 2022 14:44:57 +0000 (UTC) X-FDA: 79529939034.07.35EDDD5 Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) by imf12.hostedemail.com (Postfix) with ESMTP id 6BF6740010 for ; Wed, 1 Jun 2022 14:44:15 +0000 (UTC) Received: by mail-lj1-f181.google.com with SMTP id a23so2242195ljd.9 for ; Wed, 01 Jun 2022 07:44:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=LvrIFqHHGXUVgoifCY/oFu21MGkFJUkJFZqNI+NbYR8=; b=yUdMxLaD0W66OdCYioHhoD9gW6M1g+oPiTwhz8QjBPsmhZRk+xpyKrrZYMwaBI5XQw jZF29wuwBsRx9N/Ef1/0c3+T4sWHE9lfvTYgEsiMHIG8hfjDoNd7eBMVEOq+EIbYfQuq 9lroUnnbox8DbJ4OUbkF5AFRgPeJFaJ1g5LJcEaThvWz1dkS1fHiHSeV4xE5gOEIuLHP WlEqu0rJ8yR1wISJEvp2oCUG3dcfqARrIGtk4Mh6RoKRDLOnG4pjqMoIAoBV5xrkNfba ZHu59dGJs7depH3ibMoOoWZRMc0pm9M3SMCETLJJIkFFmHwmz8JyPj1ES6NBP8fjhql2 x2Fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=LvrIFqHHGXUVgoifCY/oFu21MGkFJUkJFZqNI+NbYR8=; b=jl+btGAmiI7grFX4sYl2ul1XI4AKS7AEHzCDF4nrMP5FNGRW19Dscp092OruRXCQuH icFOjrQxsNVYhQxVr8J00Hl9mao+/J4TaW8sTRmLHhJKsP8Qoz2zYRJJTG1XoAKMRbyq 3U+dt/OjtppMGLB8PEcC2PAv+2TsH7uGJqa9yv+Hwg3bNVjNP5coZMMReclBp0MRYsp6 QjYRlzyA2jDqLxz2PENF6AKV7zGOGkfM3WGpEzvSJTMaKlTdjGtRVZ1jU1rkecvXf61V CUhynsrgkNTRMfbYVQGBO2M6O3TQ9dENs7c3By87N0VZ8Quyh46wGrJDox2b5CBW/CEh QgUA== X-Gm-Message-State: AOAM533pW1e0F35PJSP2eJRst4TXJjO4Tb3ru0nAI8FogeupnNPVuzqz 4+QD3SkALiORBJSzI5Nd8dqVcQ== X-Google-Smtp-Source: ABdhPJzwTyr7jGZX5uox6FLAvsLwDvePrH2SadM33Ry+s6biX0Ay2qFGDYwW40N2obLPeLIf7Sxg4Q== X-Received: by 2002:a2e:a176:0:b0:253:dbf1:b023 with SMTP id u22-20020a2ea176000000b00253dbf1b023mr36240386ljl.421.1654094695470; Wed, 01 Jun 2022 07:44:55 -0700 (PDT) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id h10-20020ac250ca000000b0047255d2119fsm397178lfm.206.2022.06.01.07.44.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jun 2022 07:44:55 -0700 (PDT) Received: by box.localdomain (Postfix, from userid 1000) id E21D6109789; Wed, 1 Jun 2022 17:46:54 +0300 (+03) Date: Wed, 1 Jun 2022 17:46:54 +0300 From: "Kirill A. Shutemov" To: David Hildenbrand Cc: "Kirill A. Shutemov" , 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 , Mike Rapoport , 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 Subject: Re: [PATCHv6 03/15] efi/x86: Get full memory map in allocate_e820() Message-ID: <20220601144654.jtp6t2c6u4su4gwd@box.shutemov.name> References: <20220517153444.11195-1-kirill.shutemov@linux.intel.com> <20220517153444.11195-4-kirill.shutemov@linux.intel.com> <20220601143515.iavmtysdchirbtel@box.shutemov.name> <116f7be4-7b75-a83b-899b-c23b52534b30@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <116f7be4-7b75-a83b-899b-c23b52534b30@redhat.com> X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 6BF6740010 X-Stat-Signature: zn734zsiuy9a7zzr1wtfnxjamcrm9dh6 Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=shutemov-name.20210112.gappssmtp.com header.s=20210112 header.b=yUdMxLaD; dmarc=none; spf=none (imf12.hostedemail.com: domain of kirill@shutemov.name has no SPF policy when checking 209.85.208.181) smtp.mailfrom=kirill@shutemov.name X-HE-Tag: 1654094655-473169 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 Wed, Jun 01, 2022 at 04:39:16PM +0200, David Hildenbrand wrote: > On 01.06.22 16:35, Kirill A. Shutemov wrote: > > On Wed, Jun 01, 2022 at 11:00:23AM +0200, David Hildenbrand wrote: > >> On 17.05.22 17:34, Kirill A. Shutemov wrote: > >>> Currently allocate_e820() only interested in the size of map and size of > >>> memory descriptor to determine how many e820 entries the kernel needs. > >>> > >>> UEFI Specification version 2.9 introduces a new memory type -- > >>> unaccepted memory. To track unaccepted memory kernel needs to allocate > >>> a bitmap. The size of the bitmap is dependent on the maximum physical > >>> address present in the system. A full memory map is required to find > >>> the maximum address. > >>> > >>> Modify allocate_e820() to get a full memory map. > >> > >> Usually we use max_pfn, if we want to know the maximum pfn that's > >> present in the system (well, IIRC, excluding hotunplug). > >> > >> How exactly will this (different?) maximum from UEFI for the bitmap > >> interact with > >> > >> max_pfn = e820__end_of_ram_pfn(); > >> > >> from e820 in existing code > >> > >> ? > > > > I'm not sure I understand the question. > > Essentially, if the PFN you calculate here for the bitmap size will > essentially match later max_pfn. Yes, generally. But is can decrease if kernel transit memory from TYPE_RAM to TYPE_RESERVE. In any case we will not step out of the allocated bitmap. -- Kirill A. Shutemov