Message ID | 20230329045329.64565-1-alexghiti@rivosinc.com (mailing list archive) |
---|---|
Headers | show |
Series | Introduce 64b relocatable kernel | expand |
On Wed, 29 Mar 2023 06:53:23 +0200, Alexandre Ghiti wrote: > After multiple attempts, this patchset is now based on the fact that the > 64b kernel mapping was moved outside the linear mapping. > > The first patch allows to build relocatable kernels but is not selected > by default. That patch is a requirement for KASLR. > The second and third patches take advantage of an already existing powerpc > script that checks relocations at compile-time, and uses it for riscv. > > [...] Applied, thanks! [1/6] riscv: Prepare EFI header for relocatable kernels https://git.kernel.org/palmer/c/55de1e4ad43b [2/6] riscv: Move .rela.dyn outside of init to avoid empty relocations https://git.kernel.org/palmer/c/69a90d2fe107 [3/6] riscv: Introduce CONFIG_RELOCATABLE https://git.kernel.org/palmer/c/39b33072941f [4/6] powerpc: Move script to check relocations at compile time in scripts/ https://git.kernel.org/palmer/c/47981b5cc687 [5/6] riscv: Check relocations at compile time https://git.kernel.org/palmer/c/c2dea0bc5339 [6/6] riscv: Use --emit-relocs in order to move .rela.dyn in init https://git.kernel.org/palmer/c/559d1e45a16d Best regards,
Hello: This series was applied to riscv/linux.git (for-next) by Palmer Dabbelt <palmer@rivosinc.com>: On Wed, 29 Mar 2023 06:53:23 +0200 you wrote: > After multiple attempts, this patchset is now based on the fact that the > 64b kernel mapping was moved outside the linear mapping. > > The first patch allows to build relocatable kernels but is not selected > by default. That patch is a requirement for KASLR. > The second and third patches take advantage of an already existing powerpc > script that checks relocations at compile-time, and uses it for riscv. > > [...] Here is the summary with links: - [v9,1/6] riscv: Prepare EFI header for relocatable kernels https://git.kernel.org/riscv/c/55de1e4ad43b - [v9,2/6] riscv: Move .rela.dyn outside of init to avoid empty relocations https://git.kernel.org/riscv/c/69a90d2fe107 - [v9,3/6] riscv: Introduce CONFIG_RELOCATABLE https://git.kernel.org/riscv/c/39b33072941f - [v9,4/6] powerpc: Move script to check relocations at compile time in scripts/ https://git.kernel.org/riscv/c/47981b5cc687 - [v9,5/6] riscv: Check relocations at compile time https://git.kernel.org/riscv/c/c2dea0bc5339 - [v9,6/6] riscv: Use --emit-relocs in order to move .rela.dyn in init https://git.kernel.org/riscv/c/559d1e45a16d You are awesome, thank you!
On Tue, 28 Mar 2023 21:53:23 PDT (-0700), alexghiti@rivosinc.com wrote: > After multiple attempts, this patchset is now based on the fact that the > 64b kernel mapping was moved outside the linear mapping. > > The first patch allows to build relocatable kernels but is not selected > by default. That patch is a requirement for KASLR. > The second and third patches take advantage of an already existing powerpc > script that checks relocations at compile-time, and uses it for riscv. > > This patchset is rebased on top of: > > riscv: Use PUD/P4D/PGD pages for the linear mapping > (https://patchwork.kernel.org/project/linux-riscv/list/?series=733603) > base-commit-tag: v6.3-rc1 The QEMU CI has some way to say "this depends on an un-merged patch set sent as $MESSAGE_ID", not sure if that's a b4-ism but it's a bit less confusing. I merged this on top of the pre-merge hugepage linear mapping changes, it's on for-next. > Changes in v9: > * Fix gcc/llvm compilation errors by adding patch 1, thanks to Bjorn > * Move a patch to move rela.dyn outside of init (patch 2): it is a > separate patch to clearly explain why > * To effectively move rela.dyn to init, we need to add patch 6: separate patch since we may be > able at some point to revert (along with patch 2). > * Add a lot of orphan sections to the linker script > > Changes in v8: > * Fix UEFI boot by moving rela.dyn section into the data so that PE/COFF > loader actually copies the relocations too > * Fix check that used PGDIR instead of PUD which was not correct > for sv48 and sv57 > * Fix PE/COFF header data size definition as it led to size of 0 > > Changes in v7: > * Rebase on top of v5.15 > * Fix LDFLAGS_vmlinux which was overriden when CONFIG_DYNAMIC_FTRACE was > set > * Make relocate_kernel static > * Add Ack from Michael > > Changes in v6: > * Remove the kernel move to vmalloc zone > * Rebased on top of for-next > * Remove relocatable property from 32b kernel as the kernel is mapped in > the linear mapping and would then need to be copied physically too > * CONFIG_RELOCATABLE depends on !XIP_KERNEL > * Remove Reviewed-by from first patch as it changed a bit > > Changes in v5: > * Add "static __init" to create_kernel_page_table function as reported by > Kbuild test robot > * Add reviewed-by from Zong > * Rebase onto v5.7 > > Changes in v4: > * Fix BPF region that overlapped with kernel's as suggested by Zong > * Fix end of module region that could be larger than 2GB as suggested by Zong > * Fix the size of the vm area reserved for the kernel as we could lose > PMD_SIZE if the size was already aligned on PMD_SIZE > * Split compile time relocations check patch into 2 patches as suggested by Anup > * Applied Reviewed-by from Zong and Anup > > Changes in v3: > * Move kernel mapping to vmalloc > > Changes in v2: > * Make RELOCATABLE depend on MMU as suggested by Anup > * Rename kernel_load_addr into kernel_virt_addr as suggested by Anup > * Use __pa_symbol instead of __pa, as suggested by Zong > * Rebased on top of v5.6-rc3 > * Tested with sv48 patchset > * Add Reviewed/Tested-by from Zong and Anup > > Alexandre Ghiti (6): > riscv: Prepare EFI header for relocatable kernels > riscv: Move .rela.dyn outside of init to avoid empty relocations > riscv: Introduce CONFIG_RELOCATABLE > powerpc: Move script to check relocations at compile time in scripts/ > riscv: Check relocations at compile time > riscv: Use --emit-relocs in order to move .rela.dyn in init > > arch/powerpc/tools/relocs_check.sh | 18 ++-------- > arch/riscv/Kconfig | 14 ++++++++ > arch/riscv/Makefile | 7 ++-- > arch/riscv/Makefile.postlink | 49 ++++++++++++++++++++++++++ > arch/riscv/boot/Makefile | 7 ++++ > arch/riscv/include/asm/set_memory.h | 3 ++ > arch/riscv/kernel/efi-header.S | 19 ++++++++-- > arch/riscv/kernel/vmlinux.lds.S | 26 ++++++++++---- > arch/riscv/mm/Makefile | 4 +++ > arch/riscv/mm/init.c | 54 ++++++++++++++++++++++++++++- > arch/riscv/tools/relocs_check.sh | 26 ++++++++++++++ > scripts/relocs_check.sh | 20 +++++++++++ > 12 files changed, 218 insertions(+), 29 deletions(-) > create mode 100644 arch/riscv/Makefile.postlink > create mode 100755 arch/riscv/tools/relocs_check.sh > create mode 100755 scripts/relocs_check.sh
April 21, 2023 2:59 PM, "Palmer Dabbelt" <palmer@dabbelt.com> wrote: >> riscv: Use PUD/P4D/PGD pages for the linear mapping >> (https://patchwork.kernel.org/project/linux-riscv/list/?series=733603) >> base-commit-tag: v6.3-rc1 > > The QEMU CI has some way to say "this depends on an un-merged patch set sent as $MESSAGE_ID", not > sure if that's a b4-ism but it's a bit less confusing. I think it's patchwork-ism, actually. B4 will eventually learn to be able to include dependent series info and automatically retrieve/apply them in the proper order on "shazam", but it can't do that yet. -K
On Fri, Apr 21, 2023 at 07:10:14PM +0000, Konstantin Ryabitsev wrote: > April 21, 2023 2:59 PM, "Palmer Dabbelt" <palmer@dabbelt.com> wrote: > >> riscv: Use PUD/P4D/PGD pages for the linear mapping > >> (https://patchwork.kernel.org/project/linux-riscv/list/?series=733603) > >> base-commit-tag: v6.3-rc1 > > > > The QEMU CI has some way to say "this depends on an un-merged patch set sent as $MESSAGE_ID", not > > sure if that's a b4-ism but it's a bit less confusing. > > I think it's patchwork-ism, actually. B4 will eventually learn to be > able to include dependent series info and automatically retrieve/apply > them in the proper order on "shazam", but it can't do that yet. A patchwork-ism or a patchew-ism? Drew Jones was my source for this, but he had said the thing to do in QEMU-land was put a: Based-on: $message-id in your cover letter for each thing that you depend on. I'm not entirely sure if that meant each series or each patch. I think patchew picks that up and dumps in it on a patchew github account that the CI might pick up on. From the QEMU docs: <quote> It is also okay to base patches on top of other on-going work that is not yet part of the git master branch. To aid continuous integration tools, such as `patchew <http://patchew.org/QEMU/>`__, you should `add a tag <https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg01288.html>`__ line ``Based-on: $MESSAGE_ID`` to your cover letter to make the series dependency obvious. <\quote> FWIW, my vote is for something with a message-id, rather than those patchwork series links that you can't dump into b4!