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 94676C433EF for ; Tue, 5 Apr 2022 23:49:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AD2256B0072; Tue, 5 Apr 2022 19:48:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A80A56B0073; Tue, 5 Apr 2022 19:48:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 921616B0074; Tue, 5 Apr 2022 19:48:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 827106B0072 for ; Tue, 5 Apr 2022 19:48:53 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 31E20112F for ; Tue, 5 Apr 2022 23:48:43 +0000 (UTC) X-FDA: 79324467726.20.A866D82 Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by imf23.hostedemail.com (Postfix) with ESMTP id 5A8FA140034 for ; Tue, 5 Apr 2022 23:48:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1649202522; x=1680738522; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=tsti2G/5iL+RgXBI2ZibkXK3KW/Q8xOXVOQ6AV2zHjs=; b=FGtygVU7O+xNYQ9uFInP6D82qD4Lr+ZXuBy651SpNNycNue+8Xgx4vly zhnZi0uskqCWORfls37VWPmV+P/mWaxoMvqsILG/dLk1SDk9e12A7C2f8 DQvPy3gqgg5sYP/EDLkVtCLbENUkjCr3nwBEg2xU2LgO1DxOZJV9OqXuo aSW0UOxEKmDh7bGtxIDn4D/ZFvCQnE/H9s9X9K2xvRJgvO+fp4iXQPA72 +5725RxFAuG99UPYWAcjo+156NUgMgU4fhKPou1r2PuwjFNAh2M9JRR9t mO6jk+HbatIvarKe/UDls8uGKhG20s7DIwMD4dDKREkd9jLrYC1Dr5F4j w==; X-IronPort-AV: E=McAfee;i="6200,9189,10308"; a="321589702" X-IronPort-AV: E=Sophos;i="5.90,238,1643702400"; d="scan'208";a="321589702" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Apr 2022 16:48:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.90,238,1643702400"; d="scan'208";a="620560765" Received: from black.fi.intel.com ([10.237.72.28]) by fmsmga004.fm.intel.com with ESMTP; 05 Apr 2022 16:48:34 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 78046132; Wed, 6 Apr 2022 02:43:47 +0300 (EEST) From: "Kirill A. Shutemov" To: 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 , Dave Hansen , 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, "Kirill A. Shutemov" Subject: [PATCHv4 0/8] mm, x86/cc: Implement support for unaccepted memory Date: Wed, 6 Apr 2022 02:43:35 +0300 Message-Id: <20220405234343.74045-1-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.35.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Stat-Signature: ts8cg1466ppt78mppdrhz8gp1bjtmtbr Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=FGtygVU7; spf=none (imf23.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 134.134.136.31) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 5A8FA140034 X-HE-Tag: 1649202522-668597 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: UEFI Specification version 2.9 introduces the concept of memory acceptance: some Virtual Machine platforms, such as Intel TDX or AMD SEV-SNP, requiring memory to be accepted before it can be used by the guest. Accepting happens via a protocol specific for the Virtual Machine platform. Accepting memory is costly and it makes VMM allocate memory for the accepted guest physical address range. It's better to postpone memory acceptance until memory is needed. It lowers boot time and reduces memory overhead. The kernel needs to know what memory has been accepted. Firmware communicates this information via memory map: a new memory type -- EFI_UNACCEPTED_MEMORY -- indicates such memory. Range-based tracking works fine for firmware, but it gets bulky for the kernel: e820 has to be modified on every page acceptance. It leads to table fragmentation, but there's a limited number of entries in the e820 table Another option is to mark such memory as usable in e820 and track if the range has been accepted in a bitmap. One bit in the bitmap represents 2MiB in the address space: one 4k page is enough to track 64GiB or physical address space. In the worst-case scenario -- a huge hole in the middle of the address space -- It needs 256MiB to handle 4PiB of the address space. Any unaccepted memory that is not aligned to 2M gets accepted upfront. The approach lowers boot time substantially. Boot to shell is ~2.5x faster for 4G TDX VM and ~4x faster for 64G. Patches 1-6/7 are generic and don't have any dependencies on TDX. They should serve AMD SEV needs as well. TDX-specific code isolated in the last patch. This patch requires the core TDX patchset which is currently under review. v4: - PageBuddyUnaccepted() -> PageUnaccepted; - Use separate page_type, not shared with offline; - Rework interface between core-mm and arch code; - Adjust commit messages; - Ack from Mike; Kirill A. Shutemov (8): mm: Add support for unaccepted memory efi/x86: Get full memory map in allocate_e820() efi/x86: Implement support for unaccepted memory x86/boot/compressed: Handle unaccepted memory x86/mm: Reserve unaccepted memory bitmap x86/mm: Provide helpers for unaccepted memory x86/tdx: Unaccepted memory support mm/vmstat: Add counter for memory accepting Documentation/x86/zero-page.rst | 1 + arch/x86/Kconfig | 1 + arch/x86/boot/compressed/Makefile | 1 + arch/x86/boot/compressed/bitmap.c | 86 +++++++++++++++++++ arch/x86/boot/compressed/kaslr.c | 14 +++- arch/x86/boot/compressed/misc.c | 11 +++ arch/x86/boot/compressed/tdx.c | 41 +++++++++ arch/x86/boot/compressed/unaccepted_memory.c | 88 ++++++++++++++++++++ arch/x86/coco/tdx/tdx.c | 29 +++++-- arch/x86/include/asm/page.h | 5 ++ arch/x86/include/asm/shared/tdx.h | 20 +++++ arch/x86/include/asm/tdx.h | 19 ----- arch/x86/include/asm/unaccepted_memory.h | 15 ++++ arch/x86/include/uapi/asm/bootparam.h | 3 +- arch/x86/kernel/e820.c | 10 +++ arch/x86/mm/Makefile | 2 + arch/x86/mm/unaccepted_memory.c | 58 +++++++++++++ drivers/firmware/efi/Kconfig | 15 ++++ drivers/firmware/efi/efi.c | 1 + drivers/firmware/efi/libstub/x86-stub.c | 88 ++++++++++++++++---- include/linux/efi.h | 3 +- include/linux/page-flags.h | 24 ++++++ include/linux/vm_event_item.h | 3 + mm/internal.h | 11 +++ mm/memblock.c | 9 ++ mm/page_alloc.c | 57 ++++++++++++- mm/vmstat.c | 3 + 27 files changed, 569 insertions(+), 49 deletions(-) create mode 100644 arch/x86/boot/compressed/bitmap.c create mode 100644 arch/x86/boot/compressed/unaccepted_memory.c create mode 100644 arch/x86/include/asm/unaccepted_memory.h create mode 100644 arch/x86/mm/unaccepted_memory.c -- 2.35.1