在 2022/4/14 18:22, Ard Biesheuvel 写道:
On Thu, 14 Apr 2022 at 11:54, Wupeng Ma <mawupeng1@xxxxxxxxxx> wrote:
From: Ma Wupeng <mawupeng1@xxxxxxxxxx>
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
Memory mirroring is a technique used to separate memory into two separate
channels, usually on a memory device, like a server. In memory mirroring,
one channel is copied to another to create redundancy. This method makes
input/output (I/O) registers and memory appear with more than one address
range because the same physical byte is accessible at more than one
address. Using memory mirroring, higher memory reliability and a higher
level of memory consolidation are possible.
Arm64 can support this too. So mirrored memory support is added to support
arm64.
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.
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.
In order to test this support in arm64:
- patch this patchset
- add efi_fake_mem=8G@0:0x10000 in kernel parameter to simulate mirrored
memroy between phy addr 0-8G.
- add kernelcore=mirror in kernel parameter
- start you kernel
As I explained before:
- NAK to EFI fake_mem support on arm64
fake_mem support on arm64 will be removed in subsequent version.
- NAK to the whole series until you come up with a proposal on how to
locate the static kernel image itself into more reliable memory, as
there is really no point to any of this otherwise.
Sorry I am not familiar with this, as you metioned before,
> you have to iterate over the memory map and look for regions with
> the desired attribute, and allocate those pages explicitly.
Do you mean this is x86, commit c05cd79750fb
("x86/boot/KASLR: Prefer mirrored memory regions for the kernel physical address").
I will do some research.
> 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.
Does this bootloader refer to grub and then add minimal logic to arm64-stub.c?
What is the loader signal?
System exists mirrored memory reported by uefi?
Thanks for reviewing, sorry for my ignorance on this.
.
