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 7E771C433F5 for ; Tue, 29 Mar 2022 08:26:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7EB038D0002; Tue, 29 Mar 2022 04:26:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 772D98D0001; Tue, 29 Mar 2022 04:26:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5EC698D0002; Tue, 29 Mar 2022 04:26:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0147.hostedemail.com [216.40.44.147]) by kanga.kvack.org (Postfix) with ESMTP id 4AB1C8D0001 for ; Tue, 29 Mar 2022 04:26:27 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id D3990987BF for ; Tue, 29 Mar 2022 08:26:26 +0000 (UTC) X-FDA: 79296741972.24.597881F Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf08.hostedemail.com (Postfix) with ESMTP id 4E1A4160012 for ; Tue, 29 Mar 2022 08:26:26 +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 dfw.source.kernel.org (Postfix) with ESMTPS id 6A2BA61596 for ; Tue, 29 Mar 2022 08:26:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3D6F0C2BBE4 for ; Tue, 29 Mar 2022 08:26:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1648542385; bh=P64VippWtoDYEoAYe0HzOfZq72o+3xuuZhXnLlrgXKQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=YZikNnVohdHqaxLTAl3uRXchItLfIQ3RMnLZS5SWXUK8m6MDbfAojsLpzZl0gseOD 4+qGwXeudSkmtzBbx+rgUPcnjOVzlGB4Q649IMsroF+ZW/qcx2ALppY4MAynqZLJEu YLra/E+mx7IcMkDfxIYRvhZdh0J+140CMBB0OjX5cMYxMjERSDMnN4GiAfj//n8di9 krfNxuNGxamxbRNo2DcLkWTpeMsCDuMS281VvPDdEk+J3K3hM1xtKETjzniucSlDzQ d0s7rBROKNXh6mDsW7VCuO6jJpJkCEjQWGPQGe37m43/a2cfyk3DeBXv131zvODH2g xzsbREhnezcUQ== Received: by mail-yb1-f171.google.com with SMTP id t11so30321918ybi.6 for ; Tue, 29 Mar 2022 01:26:25 -0700 (PDT) X-Gm-Message-State: AOAM5306JLkPPndhU30iziwi2oKellVkt5XoJeH7U2yYx25yxu3C4wEG n0vkCa3chThrx0Pz/dxkO4cQxFE2K7OtzAY+zYI= X-Google-Smtp-Source: ABdhPJwfGCMLk2VB7XvUDpERYxrxLHbFQsesq9dVB+yiEVlxuw1tERLeSRhYva8E1l8LXxwAun4JZTtR9hkxp93TpLU= X-Received: by 2002:a4a:3391:0:b0:320:d78b:7957 with SMTP id q139-20020a4a3391000000b00320d78b7957mr561025ooq.60.1648542373173; Tue, 29 Mar 2022 01:26:13 -0700 (PDT) MIME-Version: 1.0 References: <20220326064632.131637-1-mawupeng1@huawei.com> In-Reply-To: <20220326064632.131637-1-mawupeng1@huawei.com> From: Ard Biesheuvel Date: Tue, 29 Mar 2022 10:26:02 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 0/9] introduce mirrored memory support for arm64 To: Wupeng Ma Cc: Andrew Morton , Catalin Marinas , Will Deacon , Jonathan Corbet , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , X86 ML , hpa@zyccr.com, Darren Hart , Andy Shevchenko , Mike Rapoport , "Paul E. McKenney" , Peter Zijlstra , Joerg Roedel , songmuchun@bytedance.com, macro@orcam.me.uk, Frederic Weisbecker , W_Armin@gmx.de, John Garry , Sean Christopherson , Thomas Bogendoerfer , Anshuman Khandual , chenhuacai@kernel.org, David Hildenbrand , gpiccoli@igalia.com, Mark Rutland , Kefeng Wang , Linux Doc Mailing List , Linux Kernel Mailing List , Linux ARM , linux-efi , linux-ia64@vger.kernel.org, platform-driver-x86@vger.kernel.org, Linux Memory Management List Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=YZikNnVo; spf=pass (imf08.hostedemail.com: domain of ardb@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ardb@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Stat-Signature: 4wbu73k7cdzj99ch1nshi7mm74ohebr9 X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 4E1A4160012 X-HE-Tag: 1648542386-90665 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 Sat, 26 Mar 2022 at 07:27, Wupeng Ma wrote: > > From: Ma Wupeng > > Commit b05b9f5f9dcf ("x86, mirror: x86 enabling - find mirrored memory ranges") > introduced mirrored memory support for x86. This support rely on UEFI to > report mirrored memory address ranges. See UEFI 2.5 spec pages 157-158: > > http://www.uefi.org/sites/default/files/resources/UEFI%202_5.pdf > > Arm64 can support this too. So mirrored memory support is added to support > arm64. > What is the point of this if the kernel itself is not loaded in EFI_MORE_RELIABLE memory? On x86, this is handled by the decompressor, but that does not exist on arm64. The problem here is that UEFI defines this as a memory *attribute* rather than a memory *type*, which means you cannot allocate EFI_MORE_RELIABLE memory easily: you have to iterate over the memory map and look for regions with the desired attribute, and allocate those pages explicitly. I'd prefer to implement this in the bootloader, and only add minimal logic to the stub to respect the placement of the kernel by the loader if the loader signals it to do so (there are other reasons for this - I will cc you on a patch shortly that implements this) This also means that the fake_mem stuff is not going to work: the memory map observed by the stub comes straight from the firmware, and if the stub needs to be involved in placing (or respecting the placement by the loader of) the kernel image, it needs to observe those EFI_MORE_RELIABLE regions too. If you don't have access to a machine that actually exposes EFI_MORE_RELIABLE memory, I suggest you prototype it in QEMU/edk2 instead. In fact, we have been trying very hard not to touch the firmware provided memory map at all on ARM, rather than use it as a scratchpad for all kinds of annotations. This means, for instance, that kexec is idempotent - the next kernel should not be affected by modifications to the memory map applied by the previous kernel. In summary, implementing kernelcore=mirror for arm64 is fine with me, but there are some issues we need to address first. > Patch #1-#2 introduce efi_fake_mem support for arm64. > Patch #3-#4 introduce mirrored memory support form arm64. > Patch #5-#7 fix some bugs for arm64 if memory reliable is enabled. > Patch #8 disable mirror feature if kernelcore is not specified. > Patch #9 remove some redundant code in ia64 efi_init. > > Ma Wupeng (9): > efi: Make efi_print_memmap() public > arm64: efi: Add fake memory support > efi: Make efi_find_mirror() public > arm64/mirror: arm64 enabling - find mirrored memory ranges > mm: Ratelimited mirrored memory related warning messages > mm: Demote warning message in vmemmap_verify() to debug level > mm: Calc the right pfn if page size is not 4K > efi: Disable mirror feature if kernelcore is not specified > ia64/efi: Code simplification in efi_init > > .../admin-guide/kernel-parameters.txt | 4 +- > arch/arm64/kernel/setup.c | 3 ++ > arch/ia64/kernel/efi.c | 37 +----------------- > arch/x86/include/asm/efi.h | 5 --- > arch/x86/platform/efi/efi.c | 39 ------------------- > drivers/firmware/efi/Kconfig | 2 +- > drivers/firmware/efi/efi.c | 26 +++++++++++++ > drivers/firmware/efi/memmap.c | 16 ++++++++ > include/linux/efi.h | 4 ++ > include/linux/mm.h | 2 + > mm/memblock.c | 4 +- > mm/page_alloc.c | 4 +- > mm/sparse-vmemmap.c | 2 +- > 13 files changed, 60 insertions(+), 88 deletions(-) > > -- > 2.18.0.huawei.25 >