From: mawupeng <mawupeng1@huawei.com>
To: <ardb@kernel.org>
Cc: <akpm@linux-foundation.org>, <catalin.marinas@arm.com>,
<will@kernel.org>, <corbet@lwn.net>, <tglx@linutronix.de>,
<mingo@redhat.com>, <bp@alien8.de>, <dave.hansen@linux.intel.com>,
<x86@kernel.org>, <hpa@zyccr.com>, <dvhart@infradead.org>,
<andy@infradead.org>, <rppt@kernel.org>, <paulmck@kernel.org>,
<peterz@infradead.org>, <jroedel@suse.de>,
<songmuchun@bytedance.com>, <macro@orcam.me.uk>,
<frederic@kernel.org>, <W_Armin@gmx.de>, <john.garry@huawei.com>,
<seanjc@google.com>, <tsbogend@alpha.franken.de>,
<anshuman.khandual@arm.com>, <chenhuacai@kernel.org>,
<david@redhat.com>, <gpiccoli@igalia.com>, <mark.rutland@arm.com>,
<wangkefeng.wang@huawei.com>, <linux-doc@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-efi@vger.kernel.org>, <linux-ia64@vger.kernel.org>,
<platform-driver-x86@vger.kernel.org>, <linux-mm@kvack.org>
Subject: Re: [PATCH 0/9] introduce mirrored memory support for arm64
Date: Tue, 29 Mar 2022 19:03:35 +0800 [thread overview]
Message-ID: <4136ec1c-51a9-3874-9bf3-c81cd88e868a@huawei.com> (raw)
In-Reply-To: <CAMj1kXEwzJE8V-tqJJwZ-RqHB3atKJvoRZ8C6_EVM7caNbttxw@mail.gmail.com>
在 2022/3/29 16:26, Ard Biesheuvel 写道:
> On Sat, 26 Mar 2022 at 07:27, Wupeng Ma <mawupeng1@huawei.com> wrote:
>>
>> From: Ma Wupeng <mawupeng1@huawei.com>
>>
>> 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.
Do you mean this is x86, commit c05cd79750fb
("x86/boot/KASLR: Prefer mirrored memory regions for the kernel physical address").
This scenario is not considered.
>
> 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)
Thanks for your incoming patch.
>
> 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.
You are right fake_mem stuff is not going to work. But, efi_fake_mem is
used for testing mirrored features and will not be used in production
environment. This test features can fake memory's attribute values.
The reason why efi_fake_mem support is put first is that memory's attribute
is reported by BIOS which is hard to simulate. With this support, any arm64
machines with efi support can easily test mirrored features.
>
> 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.
Yes, you're absolutely right. Efi_fake_mem is incompatible with kdump which
will use kexec. But we can remove specify cmdline(efi_fake_mem=xx) by
modofing /etc/sysconfig/kdump. Efi_fake_mem is only used for testing and
will not be used in production environment.
>
> In summary, implementing kernelcore=mirror for arm64 is fine with me,
> but there are some issues we need to address first.
>
Can you be clear what the issues are?
The main purpose of this patchset is to introduce mirrored support for
arm64 and we have already fixed the problems we had which is shown in
patch #5 to patch #7 and try to bring total isolation in patch #8 which
will disable mirror feature if kernelcore is not specified.
Thanks for reviewing.
>
>
>
>> 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
>>
> .
prev parent reply other threads:[~2022-03-29 11:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-26 6:46 Wupeng Ma
2022-03-26 6:46 ` [PATCH 1/9] efi: Make efi_print_memmap() public Wupeng Ma
2022-03-26 6:46 ` [PATCH 2/9] arm64: efi: Add fake memory support Wupeng Ma
2022-03-26 6:46 ` [PATCH 3/9] efi: Make efi_find_mirror() public Wupeng Ma
2022-03-26 6:46 ` [PATCH 4/9] arm64/mirror: arm64 enabling - find mirrored memory ranges Wupeng Ma
2022-03-26 6:46 ` [PATCH 5/9] mm: Ratelimited mirrored memory related warning messages Wupeng Ma
2022-03-26 6:46 ` [PATCH 6/9] mm: Demote warning message in vmemmap_verify() to debug level Wupeng Ma
2022-03-26 6:46 ` [PATCH 7/9] mm: Calc the right pfn if page size is not 4K Wupeng Ma
2022-03-28 12:33 ` David Hildenbrand
2022-03-29 1:14 ` mawupeng
2022-03-26 6:46 ` [PATCH 8/9] efi: Disable mirror feature if kernelcore is not specified Wupeng Ma
2022-03-26 6:46 ` [PATCH 9/9] ia64/efi: Code simplification in efi_init Wupeng Ma
2022-03-29 8:26 ` [PATCH 0/9] introduce mirrored memory support for arm64 Ard Biesheuvel
2022-03-29 11:03 ` mawupeng [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4136ec1c-51a9-3874-9bf3-c81cd88e868a@huawei.com \
--to=mawupeng1@huawei.com \
--cc=W_Armin@gmx.de \
--cc=akpm@linux-foundation.org \
--cc=andy@infradead.org \
--cc=anshuman.khandual@arm.com \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=chenhuacai@kernel.org \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=dvhart@infradead.org \
--cc=frederic@kernel.org \
--cc=gpiccoli@igalia.com \
--cc=hpa@zyccr.com \
--cc=john.garry@huawei.com \
--cc=jroedel@suse.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=macro@orcam.me.uk \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rppt@kernel.org \
--cc=seanjc@google.com \
--cc=songmuchun@bytedance.com \
--cc=tglx@linutronix.de \
--cc=tsbogend@alpha.franken.de \
--cc=wangkefeng.wang@huawei.com \
--cc=will@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox