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 C9AC7CCA468 for ; Wed, 1 Jun 2022 14:33:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2C94C8D001B; Wed, 1 Jun 2022 10:33:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 278A78D000E; Wed, 1 Jun 2022 10:33:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 165F88D001B; Wed, 1 Jun 2022 10:33:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 0798E8D000E for ; Wed, 1 Jun 2022 10:33:19 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id BEC5FA5C for ; Wed, 1 Jun 2022 14:33:18 +0000 (UTC) X-FDA: 79529909676.13.43EB66F Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) by imf22.hostedemail.com (Postfix) with ESMTP id CCD95C006E for ; Wed, 1 Jun 2022 14:33:14 +0000 (UTC) Received: by mail-lj1-f176.google.com with SMTP id v9so2189073lja.12 for ; Wed, 01 Jun 2022 07:33:17 -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=ZCSZBRlbrl+wVf2rxucv5zcNIA855Ca5kZwzalOYvb0=; b=VVLJD0NAQILvJHfkfQdPPcZQYLPIvuU383slFb0XqyUhc32YzHWh5sxJyXBVFHQYJy J92H5Fw4LbWBvdWB1iS6I3yvfJJWHZw8bqQDOC6b44r7JyavcgRc2mBCUj6eeznjSuDk nyIxkcatYhb+zHY7xIfeQHW+2ukP9E+RdX9pYQ/ykkIXmvJS9ayfu/0ACvyDq232jvYe SeMxgVf6YbK4Dc0/HecM5JX7ykfd2b36y1SR6Q6Szo5lJNS5UckHGL7PzNDLGZF4Hv2p M18Yixf8P1Cs2Qz2tWaphg/Rz3oQ7A+VQVQtbOGBofEaAAzm/2V2dk8Dql19ozH6RH8U GKhA== 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=ZCSZBRlbrl+wVf2rxucv5zcNIA855Ca5kZwzalOYvb0=; b=mmzlboQ8dn1EJTPtTFtB5A7q1tGo1AnX6NOOxCjmgyPL2h0GISoUbXIrbz+RWXDugc cThq8Xpduu3KyK5sxkfpo5SK9wb0XxqWQDlArasgrauErvtv2+/IM5jU6lrM0y4hcO7x mJw1msg+TfhIB5GyST0QRFHY+5R5HI5PcaRMPcsMthcOIyBD/qthiJxXw+05MGhxfFmB SODNArNX0zAScY0oYoEIhM2TWyC4ETxdRabOCe951qUtnTm+uDPpJKMoBviKldcaVcnn WNPfz1VeOxwAr92GhXNSeBtlBu/pZmN2yOvsbs/TT+zlNP2IxzX0NaKDLz0Q2JwDUWU2 tjJQ== X-Gm-Message-State: AOAM533Q80fNaKUIe9E/gB4aN5dKls7PbIlRCW3xoy7ztDDpu6TbEkxo 9Pj1iVJ77/rB2OM3Eth7smhzFA== X-Google-Smtp-Source: ABdhPJxwZgIPL7egdv7c+WP6CgrkdcITk/oDwU0+MJ0tE1U4J5QLdAPVS/TIaa7FdZYS+ZxQQIntVA== X-Received: by 2002:a2e:920f:0:b0:255:4f66:956 with SMTP id k15-20020a2e920f000000b002554f660956mr9356579ljg.191.1654093996359; Wed, 01 Jun 2022 07:33:16 -0700 (PDT) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id o8-20020a056512230800b00478feae4f24sm388181lfu.268.2022.06.01.07.33.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jun 2022 07:33:15 -0700 (PDT) Received: by box.localdomain (Postfix, from userid 1000) id 0A26E109789; Wed, 1 Jun 2022 17:35:15 +0300 (+03) Date: Wed, 1 Jun 2022 17:35:15 +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: <20220601143515.iavmtysdchirbtel@box.shutemov.name> References: <20220517153444.11195-1-kirill.shutemov@linux.intel.com> <20220517153444.11195-4-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=shutemov-name.20210112.gappssmtp.com header.s=20210112 header.b=VVLJD0NA; dmarc=none; spf=none (imf22.hostedemail.com: domain of kirill@shutemov.name has no SPF policy when checking 209.85.208.176) smtp.mailfrom=kirill@shutemov.name X-Stat-Signature: aicu9d3jyqyjjf6wmyg54sm9jwyof4ye X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: CCD95C006E X-HE-Tag: 1654093994-669263 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 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. On EFI system, E820 is constructed based on EFI memory map and size of bitmap calculated based of EFI memmap will always be enough to address all memory. e820__end_of_ram_pfn() can be smaller than what what we calculate as size of memory here, if kernel reserve very top of the memory, but it will never be larger. Later during the boot we use e820__end_of_ram_pfn() to infer size of bitmap and it is safe. -- Kirill A. Shutemov