| Message ID | 20220414101314.1250667-1-mawupeng1@huawei.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | introduce mirrored memory support for arm64 | expand |
On Thu, 14 Apr 2022 at 11:54, 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 > > 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 - 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.
在 2022/4/14 18:22, Ard Biesheuvel 写道: > On Thu, 14 Apr 2022 at 11:54, 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 >> >> 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. > .
On Sat, 16 Apr 2022 at 03:32, mawupeng <mawupeng1@huawei.com> wrote: > > > > 在 2022/4/14 18:22, Ard Biesheuvel 写道: > > On Thu, 14 Apr 2022 at 11:54, 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 > >> > >> 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? > Any bootloader, yes. > What is the loader signal? A protocol installed onto the image handle, as I suggested before. I even cc'ed you on a patch that implements this. > System exists mirrored memory reported by uefi? > What on earth is the point of any of this if the only use case being targeted is efi_fake_mem with arbitrary fake mirrored regions? So yes, unless there are systems that need this, I don't see a point in merging any of this.
在 2022/4/20 2:32, Ard Biesheuvel 写道: > On Sat, 16 Apr 2022 at 03:32, mawupeng <mawupeng1@huawei.com> wrote: >> >> >> >> 在 2022/4/14 18:22, Ard Biesheuvel 写道: >>> On Thu, 14 Apr 2022 at 11:54, 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 >>>> >>>> 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? >> > > Any bootloader, yes. > >> What is the loader signal? > > A protocol installed onto the image handle, as I suggested before. I > even cc'ed you on a patch that implements this. Sorry to bother you. I didn't receive any patches. Could you share the link? > >> System exists mirrored memory reported by uefi? >> > > What on earth is the point of any of this if the only use case being > targeted is efi_fake_mem with arbitrary fake mirrored regions? > > So yes, unless there are systems that need this, I don't see a point > in merging any of this We do have mirrored memory reported by uefi and efi_fake_mem is added for easy testing with qemu/hardware without update UEFI. > .
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 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 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 kernelPHYS_PFNcore is not specified. Patch #9 remove some redundant code in ia64 efi_init. Changelog since v1: - update changelog in cover letter - use PHYS_PFN in patch #7 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(-)