Re: [kexec-tools][PATCH] ARM: Fix add_buffer_phys_virt() align issue
On Wed, Apr 24, 2024 at 02:17:27PM +0200, Alexander Kanavin wrote: > From: Haiqing Bai > > When "CONFIG_ARM_LPAE" is enabled,3 level page table > is used by MMU, the "SECTION_SIZE" is defined with > (1 << 21), but 'add_buffer_phys_virt()' hardcode this > to (1 << 20). > > Suggested-By: fredrik.markst...@gmail.com > Signed-off-by: Haiqing Bai > Signed-off-by: Alexander Kanavin Thanks, applied. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] Fix incorrect Free Software Foundation address in the license
On Mon, Apr 08, 2024 at 02:37:55PM +0800, Coiby Xu wrote: > As detected by rpmlint, > kexec-tools.x86_64: E: incorrect-fsf-address > /usr/share/licenses/kexec-tools/COPYING > The Free Software Foundation address in this file seems to be outdated or > misspelled. Ask upstream to update the address, or if this is a license > file, > possibly the entire file with a new copy available from the FSF. > > Replace current one with > https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt > to fix this issue. > > Signed-off-by: Coiby Xu Thanks, applied. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] crashdump-x86.c:Add a check for the crash kernel range in exclude_region()
On Thu, Mar 21, 2024 at 07:33:17PM +0800, chenhaixiang wrote: > In some cases, such as start < mstart < mend < end when exclude_region(), > this results in crash_memory_range[i].end becoming less than > crash_memory_range[i].start, leading to incorrect address ranges. > Adding a range check should be necessary. > > Signed-off-by: chenhaixiang chenhaixia...@huawei.com Hi, Given the discussion at [1] I am assuming this patch should not go in. Please correct me if I am wrong. [1] https://lore.kernel.org/all/8606fd02d6de4eb3b7c80e4ce3449...@huawei.com/ ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] crash: Fix spelling mistake: "crahskernel" -> "crashkernel"
On Fri, Apr 19, 2024 at 09:52:06AM +0100, Colin Ian King wrote: > There is a spelling mistake in a pr_warn message. Fix it. > > Signed-off-by: Colin Ian King Reviewed-by: Simon Horman ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] util_lib/elf_info.c: fix a warning
On Thu, Mar 21, 2024 at 03:30:37PM +0800, Baoquan He wrote: > There's a incorrect array operation in function scan_vmcoreinfo(), it > will cause below warning message. > > --- > util_lib/elf_info.c: In function ‘scan_vmcoreinfo’: > util_lib/elf_info.c:360:43: warning: writing 1 byte into a region of size 0 > [-Wstringop-overflow=] > 360 | temp_buf[len + 1] = '\0'; > | ~~^~ > util_lib/elf_info.c:319:14: note: at offset 1024 into destination object > ‘temp_buf’ of size 1024 > 319 | char temp_buf[1024]; > | ^~~~ > - > > Fix it to avoid oob access of array. > > Signed-off-by: Baoquan He Thanks, applied. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] kexec_file: add kexec_file flag to support debug printing
On Fri, Mar 15, 2024 at 04:11:50PM +0800, Baoquan He wrote: > On 11/27/23 at 01:32pm, Simon Horman wrote: > > On Tue, Nov 14, 2023 at 11:20:30PM +0800, Baoquan He wrote: > > > This add KEXEC_FILE_DEBUG to kexec_file_flags so that it can be passed > > > to kernel when '-d' is added with kexec_file_load interface. With that > > > flag enabled, kernel can enable the debugging message printing. > > > > > > Signed-off-by: Baoquan He > > > > Thanks, > > > > this looks fine to me. > > But perhaps the corresponding Kernel patch should land first? > > Let me know what you think. > > Ping, the relevant kernel patches landed in mainline kernel, please help > merge this patch. Thanks, applied. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH kexec-tools] workflow: update to use checkout@v4
On Fri, Feb 02, 2024 at 09:55:41AM +0100, Simon Horman wrote: > Update to use checkout@v4. > > This addresses the following warning that appears in GitHub runs: > > "Node.js 16 actions are deprecated. Please update the following actions > to use Node.js 20: actions/checkout@v3. For more information > see: > https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/. > > Link: https://github.com/horms/kexec-tools/actions/runs/7753454923 > Signed-off-by: Simon Horman Applied. - workflow: update to use checkout@v4 https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/commit/?id=6ee2ac1bf739 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] kexec-tools: purgatory: fix build on `binutils-2.42`
On Fri, Feb 02, 2024 at 12:16:38PM +0800, Baoquan He wrote: > On 02/02/24 at 11:01am, Coiby Xu wrote: > > Hi, > > > > FYI, before this patch, Michel already sent "[PATCH] Fix building on x86_64 > > with binutils 2.41" to address the same issue. Currently I almost know > > nothing about > > assembly but Michel's patch seems to be more complete because two more > > files are touched. > > Thanks for telling, I didn't notice that one. I didn't know these > either, leave them to Sergei and Michel to decide what is the > appropriate solution. Hi, I did go ahead and apply Michael's patch. Let's follow-up with incremental changes if necessary. ... ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH kexec-tools] workflow: update to use checkout@v4
Update to use checkout@v4. This addresses the following warning that appears in GitHub runs: "Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: actions/checkout@v3. For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/. Link: https://github.com/horms/kexec-tools/actions/runs/7753454923 Signed-off-by: Simon Horman --- .github/workflows/build.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml index d0007f14b274..46edde66e384 100644 --- a/.github/workflows/build.yml +++ b/.github/workflows/build.yml @@ -28,7 +28,7 @@ jobs: libxen: libxen steps: - name: Checkout - uses: actions/checkout@v3 + uses: actions/checkout@v4 - name: Set Environment env: ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] Fix building on x86_64 with binutils 2.41
On Tue, Jan 30, 2024 at 04:14:31AM -0600, Michel Lind via B4 Relay wrote: > From: Michel Lind > > Newer versions of the GNU assembler (observed with binutils 2.41) will > complain about the ".arch i386" in files assembled with "as --64", > with the message "Error: 64bit mode not supported on 'i386'". > > Fix by moving ".arch i386" below the relevant ".code32" directive, so > that the assembler is no longer expecting 64-bit instructions to be used > by the time that the ".arch i386" directive is encountered. > > Based on similar iPXE fix: > https://github.com/ipxe/ipxe/commit/6ca597eee > > Signed-off-by: Michel Lind Thanks Michael, applied. - Fix building on x86_64 with binutils 2.41 https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/commit/?id=328de8e00e29 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH -next] kexec: Remove duplicated include in crash_reserve.c
On Fri, Jan 26, 2024 at 08:44:49AM +0800, Yang Li wrote: > The header files kexec.h is included twice in crash_reserve.c, > so one inclusion can be removed. > > Signed-off-by: Yang Li Reviewed-by: Simon Horman ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] kexec: don't use kexec_file_load on XEN
On Tue, Jan 16, 2024 at 06:14:31PM +0100, Jiri Bohac wrote:
> Since commit 29fe5067ed07 ("kexec: make -a the default")
> kexec tries the kexec_file_load syscall first and only falls back to
> kexec_load on
> selected error codes.
>
> This effectively breaks kexec on XEN, unless -c is pecified to force the
> kexec_load
> syscall.
>
> The XEN-specific functions (xen_kexec_load / xen_kexec_unload) are only called
> from my_load / k_unload, i.e. the kexec_load code path.
>
> With -p (panic kernel) kexec_file_load on XEN fails with -EADDRNOTAVAIL (crash
> kernel reservation is ignored by the kernel on XEN), which is not in the list
> of return codes that cause the fallback to kexec_file.
>
> Without -p kexec_file_load actualy leads to a kernel oops on v6.4.0
> (needs to be dubugged separately).
>
> Signed-off-by: Jiri Bohac
> Fixes: 29fe5067ed07 ("kexec: make -a the default")
Thanks Jiri,
and sorry for the delay.
Applied to main.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[ANNOUNCE] kexec-tools 2.0.28
Hi all, I am happy to announce the release of kexec-tools 2.0.28. This is a feature release coinciding with the release of v6.7 of the Linux Kernel. This release can be downloaded from kernel.org: http://kernel.org/pub/linux/utils/kernel/kexec/kexec-tools-2.0.28.tar.xz http://kernel.org/pub/linux/utils/kernel/kexec/ It is also tagged it in git: git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git Thanks to everyone who has contributed to kexec! Commits since v2.0.27: adef8a8e4bfd kexec-tools 2.0.28 5d7bc25cf15b kexec-tools 2.0.28-rc1 549466430ae6 LoongArch: Load vmlinux.efi to the link address ba0ac0efe299 LoongArch: Fix an issue with relocatable vmlinux 74dfaefd6316 m68k: fix getrandom() use with uclibc 22dcf5cb940a lzma: Relax memory limit for lzma decompressor 44e7b73c331f kexec: ppc64: print help to stdout instead of stderr 74d66d405f30 workflow: update to Ubuntu 22.04 ab3a70af8567 kexec/loongarch64: fix 'make dist' file loss issue 6419b008fde7 kexec: provide a memfd_create() wrapper if not present in libc 118b567ce74a crashdump/x86: set the elfcorehdr segment size for hotplug d59d17f37239 crashdump/x86: identify elfcorehdr segment for hotplug a56376080a93 crashdump: exclude elfcorehdr segment from digest for hotplug 75ac71fd94ff crashdump: setup general hotplug support d6cfd2984844 crashdump: introduce the hotplug command line options c36d3e8b2e99 kexec: define KEXEC_UPDATE_ELFCOREHDR bd0200c47c45 kexec: update manpage with explicit mention of clean kexec 2495ccfc5206 zboot: add loongarch kexec_load support 8f08e3b51f25 zboot: enable arm64 kexec_load for zboot image c3f35ff06e54 build: fix tarball creation 056c179cd3c2 kexec-tools 2.0.27.git ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[ANNOUNCE] kexec-tools 2.0.28-rc1
Hi all, I am happy to announce the release of kexec-tools 2.0.28-rc1. This is an incremental feature pre-release. So long as no serious problems arise I intend to release kexec-tools 2.0.28 in a weeks time. Testing of 2.0.28-rc1 would be greatly appreciated. I do not have any outstanding changes for 2.0.28 at this time. And I would like to only accept bug fixes at this time and take features patches once 2.0.28 has been released. The pre-release can be downloaded from kernel.org: https://kernel.org/pub/linux/utils/kernel/kexec/kexec-tools-2.0.28-rc1.tar.xz https://kernel.org/pub/linux/utils/kernel/kexec/ I have also tagged it in git: https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git Thanks to everyone who has contributed to kexec. For reference the changes since v2.0.27 are: 5d7bc25cf15b kexec-tools 2.0.28-rc1 549466430ae6 LoongArch: Load vmlinux.efi to the link address ba0ac0efe299 LoongArch: Fix an issue with relocatable vmlinux 74dfaefd6316 m68k: fix getrandom() use with uclibc 22dcf5cb940a lzma: Relax memory limit for lzma decompressor 44e7b73c331f kexec: ppc64: print help to stdout instead of stderr 74d66d405f30 workflow: update to Ubuntu 22.04 ab3a70af8567 kexec/loongarch64: fix 'make dist' file loss issue 6419b008fde7 kexec: provide a memfd_create() wrapper if not present in libc 118b567ce74a crashdump/x86: set the elfcorehdr segment size for hotplug d59d17f37239 crashdump/x86: identify elfcorehdr segment for hotplug a56376080a93 crashdump: exclude elfcorehdr segment from digest for hotplug 75ac71fd94ff crashdump: setup general hotplug support d6cfd2984844 crashdump: introduce the hotplug command line options c36d3e8b2e99 kexec: define KEXEC_UPDATE_ELFCOREHDR bd0200c47c45 kexec: update manpage with explicit mention of clean kexec 2495ccfc5206 zboot: add loongarch kexec_load support 8f08e3b51f25 zboot: enable arm64 kexec_load for zboot image c3f35ff06e54 build: fix tarball creation 056c179cd3c2 kexec-tools 2.0.27.git ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[ANNOUNCE] kexec-tools v2.0.28 preparation
Hi all, I am planning to release kexec-tools v2.0.28 in the next two weeks to roughly coincide with the release of the v6.7 kernel. I would like to ask interested parties to send any patches they would like included in v2.0.28 within one week so they can be considered for inclusion in an rc release. For reference the patches queued up since v2.0.27 are as follows. Thanks to everyone who has contributed to kexec-tools! 549466430ae6 LoongArch: Load vmlinux.efi to the link address ba0ac0efe299 LoongArch: Fix an issue with relocatable vmlinux 74dfaefd6316 m68k: fix getrandom() use with uclibc 22dcf5cb940a lzma: Relax memory limit for lzma decompressor 44e7b73c331f kexec: ppc64: print help to stdout instead of stderr 74d66d405f30 workflow: update to Ubuntu 22.04 ab3a70af8567 kexec/loongarch64: fix 'make dist' file loss issue 6419b008fde7 kexec: provide a memfd_create() wrapper if not present in libc 118b567ce74a crashdump/x86: set the elfcorehdr segment size for hotplug d59d17f37239 crashdump/x86: identify elfcorehdr segment for hotplug a56376080a93 crashdump: exclude elfcorehdr segment from digest for hotplug 75ac71fd94ff crashdump: setup general hotplug support d6cfd2984844 crashdump: introduce the hotplug command line options c36d3e8b2e99 kexec: define KEXEC_UPDATE_ELFCOREHDR bd0200c47c45 kexec: update manpage with explicit mention of clean kexec 2495ccfc5206 zboot: add loongarch kexec_load support 8f08e3b51f25 zboot: enable arm64 kexec_load for zboot image c3f35ff06e54 build: fix tarball creation 056c179cd3c2 kexec-tools 2.0.27.git ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] LoongArch: Load vmlinux.efi to the link address
On Sat, Dec 02, 2023 at 10:03:29PM +0800, Huacai Chen wrote:
> On Sat, Dec 2, 2023 at 8:46 PM Simon Horman wrote:
> >
> > On Sat, Dec 02, 2023 at 08:30:27PM +0800, Huacai Chen wrote:
> > > On Sat, Dec 2, 2023 at 6:11 PM WANG Rui wrote:
> > > >
> > > > > On Fri, Nov 24, 2023 at 11:46:58PM +0800, WANG Rui wrote:
> > > > > > Currently, kexec loads vmlinux.efi to address 0 instead of the link
> > > > > > address. This causes kexec to fail to boot the new vmlinux.efi on
> > > > > > qemu.
> > > > > >
> > > > > > pei_loongarch_load: kernel_segment:
> > > > > > pei_loongarch_load: kernel_entry: 015dc000
> > > > > > pei_loongarch_load: image_size: 01f3
> > > > > > pei_loongarch_load: text_offset:0020
> > > > > > pei_loongarch_load: phys_offset:
> > > > > > pei_loongarch_load: PE format: yes
> > > > > > loongarch_load_other_segments:333: command_line: kexec
> > > > > > console=ttyS0,115200
> > > > > > kexec_load: entry = 0x15dc000 flags = 0x102
> > > > > > nr_segments = 2
> > > > > > segment[0].buf = 0x7fffef664010
> > > > > > segment[0].bufsz = 0x1de9a00
> > > > > > segment[0].mem = (nil)
> > > > > > segment[0].memsz = 0x1f3
> > > > > > segment[1].buf = 0x55e480b0
> > > > > > segment[1].bufsz = 0x200
> > > > > > segment[1].mem = 0x1f3
> > > > > > segment[1].memsz = 0x4000
> > > > > >
> > > > > > This patch adds `text_offset` when adding kernel segment to load
> > > > > > vmlinux.efi to the link address.
> > > > > >
> > > > > > pei_loongarch_load: kernel_segment:
> > > > > > pei_loongarch_load: kernel_entry: 015dc000
> > > > > > pei_loongarch_load: image_size: 01f3
> > > > > > pei_loongarch_load: text_offset:0020
> > > > > > pei_loongarch_load: phys_offset:
> > > > > > pei_loongarch_load: PE format: yes
> > > > > > loongarch_load_other_segments:335: command_line: kexec
> > > > > > console=ttyS0,115200
> > > > > > kexec_load: entry = 0x15dc000 flags = 0x102
> > > > > > nr_segments = 2
> > > > > > segment[0].buf = 0x71a04010
> > > > > > segment[0].bufsz = 0x1de9a00
> > > > > > segment[0].mem = 0x20
> > > > > > segment[0].memsz = 0x1f3
> > > > > > segment[1].buf = 0x55b28098
> > > > > > segment[1].bufsz = 0x200
> > > > > > segment[1].mem = 0x213
> > > > > > segment[1].memsz = 0x4000
> > > > > >
> > > > > > Signed-off-by: WANG Rui
> > > > >
> > > > > Thanks, applied.
> > > >
> > > > Hi Simon,
> > > >
> > > > The patch v1 breaks the real machine. Could you please revert it and
> > > > just keep v2? Thanks.
> > > Hmmm, if possible, I suggest resetting the old commit before v1 and
> > > only apply v2... The current status makes the history very very
> > > confusing.
> >
> > Thanks, I would rather not drop patches from the tree as it changes
> > the hashes of the tree from that point. However, in this case, I agree
> > that a simple revert makes things confusing, so I have done as you suggest
> > - v1 has been dropped from the tree.
> >
> > Can you please check that the tree as of the following commit, which is
> > now the HEAD commit of the main branch, is correct?
> >
> > 549466430ae6 ("LoongArch: Load vmlinux.efi to the link address")
> Thank you, it is perfect now.
Thanks for bringing this to my attention and thanks for checking.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] LoongArch: Load vmlinux.efi to the link address
On Sat, Dec 02, 2023 at 08:30:27PM +0800, Huacai Chen wrote:
> On Sat, Dec 2, 2023 at 6:11 PM WANG Rui wrote:
> >
> > > On Fri, Nov 24, 2023 at 11:46:58PM +0800, WANG Rui wrote:
> > > > Currently, kexec loads vmlinux.efi to address 0 instead of the link
> > > > address. This causes kexec to fail to boot the new vmlinux.efi on qemu.
> > > >
> > > > pei_loongarch_load: kernel_segment:
> > > > pei_loongarch_load: kernel_entry: 015dc000
> > > > pei_loongarch_load: image_size: 01f3
> > > > pei_loongarch_load: text_offset:0020
> > > > pei_loongarch_load: phys_offset:
> > > > pei_loongarch_load: PE format: yes
> > > > loongarch_load_other_segments:333: command_line: kexec
> > > > console=ttyS0,115200
> > > > kexec_load: entry = 0x15dc000 flags = 0x102
> > > > nr_segments = 2
> > > > segment[0].buf = 0x7fffef664010
> > > > segment[0].bufsz = 0x1de9a00
> > > > segment[0].mem = (nil)
> > > > segment[0].memsz = 0x1f3
> > > > segment[1].buf = 0x55e480b0
> > > > segment[1].bufsz = 0x200
> > > > segment[1].mem = 0x1f3
> > > > segment[1].memsz = 0x4000
> > > >
> > > > This patch adds `text_offset` when adding kernel segment to load
> > > > vmlinux.efi to the link address.
> > > >
> > > > pei_loongarch_load: kernel_segment:
> > > > pei_loongarch_load: kernel_entry: 015dc000
> > > > pei_loongarch_load: image_size: 01f3
> > > > pei_loongarch_load: text_offset:0020
> > > > pei_loongarch_load: phys_offset:
> > > > pei_loongarch_load: PE format: yes
> > > > loongarch_load_other_segments:335: command_line: kexec
> > > > console=ttyS0,115200
> > > > kexec_load: entry = 0x15dc000 flags = 0x102
> > > > nr_segments = 2
> > > > segment[0].buf = 0x71a04010
> > > > segment[0].bufsz = 0x1de9a00
> > > > segment[0].mem = 0x20
> > > > segment[0].memsz = 0x1f3
> > > > segment[1].buf = 0x55b28098
> > > > segment[1].bufsz = 0x200
> > > > segment[1].mem = 0x213
> > > > segment[1].memsz = 0x4000
> > > >
> > > > Signed-off-by: WANG Rui
> > >
> > > Thanks, applied.
> >
> > Hi Simon,
> >
> > The patch v1 breaks the real machine. Could you please revert it and just
> > keep v2? Thanks.
> Hmmm, if possible, I suggest resetting the old commit before v1 and
> only apply v2... The current status makes the history very very
> confusing.
Thanks, I would rather not drop patches from the tree as it changes
the hashes of the tree from that point. However, in this case, I agree
that a simple revert makes things confusing, so I have done as you suggest
- v1 has been dropped from the tree.
Can you please check that the tree as of the following commit, which is
now the HEAD commit of the main branch, is correct?
549466430ae6 ("LoongArch: Load vmlinux.efi to the link address")
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] LoongArch: Load vmlinux.efi to the link address
On Fri, Dec 01, 2023 at 10:54:49PM +0800, Huacai Chen wrote: > Hi, Simon, > > On Fri, Dec 1, 2023 at 10:06 PM Simon Horman wrote: > > > > On Wed, Nov 29, 2023 at 12:15:17PM +0800, Huacai Chen wrote: > > > Hi, all, > > > > > > On Tue, Nov 28, 2023 at 2:27 PM WANG Rui wrote: > > > > > > > > Hi, > > > > > > > > On Mon, Nov 27, 2023 at 10:36 AM RuiRui Yang wrote: > > > > > > > > > > On Mon, 27 Nov 2023 at 09:53, RuiRui Yang wrote: > > > > > > > > > > > > On Sat, 25 Nov 2023 at 14:54, WANG Rui wrote: > > > > > > > > > > > > > > Currently, kexec loads vmlinux.efi to address 0 instead of the > > > > > > > link > > > > > > > address. This causes kexec to fail to boot the new vmlinux.efi on > > > > > > > qemu. > > > > > > > > > > > > > > pei_loongarch_load: kernel_segment: > > > > > > > pei_loongarch_load: kernel_entry: 013f1000 > > > > > > > pei_loongarch_load: image_size: 01ca > > > > > > > pei_loongarch_load: text_offset:0020 > > > > > > > pei_loongarch_load: phys_offset: > > > > > > > pei_loongarch_load: PE format: yes > > > > > > > loongarch_load_other_segments:333: command_line: kexec > > > > > > > console=ttyS0,115200 > > > > > > > kexec_load: entry = 0x13f1000 flags = 0x102 > > > > > > > nr_segments = 2 > > > > > > > segment[0].buf = 0x7fffeea38010 > > > > > > > segment[0].bufsz = 0x1b55200 > > > > > > > segment[0].mem = (nil) > > > > > > > segment[0].memsz = 0x1ca > > > > > > > segment[1].buf = 0x570940b0 > > > > > > > segment[1].bufsz = 0x200 > > > > > > > segment[1].mem = 0x1ca > > > > > > > segment[1].memsz = 0x4000 > > > > > > > > > > > > > > This patch constrains the range of the kernel segment by > > > > > > > `hole_min` > > > > > > > and `hole_max` to place vmlinux.efi exactly at the link address. > > > > > > > > > > > > > > pei_loongarch_load: kernel_segment: 0020 > > > > > > > pei_loongarch_load: kernel_entry: 013f1000 > > > > > > > pei_loongarch_load: image_size: 01ca > > > > > > > pei_loongarch_load: text_offset:0020 > > > > > > > pei_loongarch_load: phys_offset: > > > > > > > pei_loongarch_load: PE format: yes > > > > > > > loongarch_load_other_segments:339: command_line: kexec > > > > > > > console=ttyS0,115200 > > > > > > > kexec_load: entry = 0x13f1000 flags = 0x102 > > > > > > > nr_segments = 2 > > > > > > > segment[0].buf = 0x72028010 > > > > > > > segment[0].bufsz = 0x1b55200 > > > > > > > segment[0].mem = 0x20 > > > > > > > segment[0].memsz = 0x1ca > > > > > > > segment[1].buf = 0x57498098 > > > > > > > segment[1].bufsz = 0x200 > > > > > > > segment[1].mem = 0x1ea > > > > > > > segment[1].memsz = 0x4000 > > > > > > > > > > > > > > Signed-off-by: WANG Rui > > > > > > > --- > > > > > > > > > > > > > > v1->v2: > > > > > > > * Fix the issue preventing it from working on the physical > > > > > > > machine. > > > > > > > > > > > > > > kexec/arch/loongarch/kexec-loongarch.c | 10 +++--- > > > > > > > 1 file changed, 7 insertions(+), 3 deletions(-) > > > > > > > > > > > > > > diff --git a/kexec/arch/loongarch/kexec-loongarch.c > > > > > > > b/kexec/arch/loongarch/kexec-loongarch.c > > > > > > > index 62ff8fd..32a42d2 100644 > > > > > > > --- a/kexec/arch/loongarch/kexec-loongarch.c > > > > > > > +++ b/kexec/arch/loongarch/kexec-
Re: [PATCH v2] LoongArch: Load vmlinux.efi to the link address
On Wed, Nov 29, 2023 at 12:15:17PM +0800, Huacai Chen wrote:
> Hi, all,
>
> On Tue, Nov 28, 2023 at 2:27 PM WANG Rui wrote:
> >
> > Hi,
> >
> > On Mon, Nov 27, 2023 at 10:36 AM RuiRui Yang wrote:
> > >
> > > On Mon, 27 Nov 2023 at 09:53, RuiRui Yang wrote:
> > > >
> > > > On Sat, 25 Nov 2023 at 14:54, WANG Rui wrote:
> > > > >
> > > > > Currently, kexec loads vmlinux.efi to address 0 instead of the link
> > > > > address. This causes kexec to fail to boot the new vmlinux.efi on
> > > > > qemu.
> > > > >
> > > > > pei_loongarch_load: kernel_segment:
> > > > > pei_loongarch_load: kernel_entry: 013f1000
> > > > > pei_loongarch_load: image_size: 01ca
> > > > > pei_loongarch_load: text_offset:0020
> > > > > pei_loongarch_load: phys_offset:
> > > > > pei_loongarch_load: PE format: yes
> > > > > loongarch_load_other_segments:333: command_line: kexec
> > > > > console=ttyS0,115200
> > > > > kexec_load: entry = 0x13f1000 flags = 0x102
> > > > > nr_segments = 2
> > > > > segment[0].buf = 0x7fffeea38010
> > > > > segment[0].bufsz = 0x1b55200
> > > > > segment[0].mem = (nil)
> > > > > segment[0].memsz = 0x1ca
> > > > > segment[1].buf = 0x570940b0
> > > > > segment[1].bufsz = 0x200
> > > > > segment[1].mem = 0x1ca
> > > > > segment[1].memsz = 0x4000
> > > > >
> > > > > This patch constrains the range of the kernel segment by `hole_min`
> > > > > and `hole_max` to place vmlinux.efi exactly at the link address.
> > > > >
> > > > > pei_loongarch_load: kernel_segment: 0020
> > > > > pei_loongarch_load: kernel_entry: 013f1000
> > > > > pei_loongarch_load: image_size: 01ca
> > > > > pei_loongarch_load: text_offset:0020
> > > > > pei_loongarch_load: phys_offset:
> > > > > pei_loongarch_load: PE format: yes
> > > > > loongarch_load_other_segments:339: command_line: kexec
> > > > > console=ttyS0,115200
> > > > > kexec_load: entry = 0x13f1000 flags = 0x102
> > > > > nr_segments = 2
> > > > > segment[0].buf = 0x72028010
> > > > > segment[0].bufsz = 0x1b55200
> > > > > segment[0].mem = 0x20
> > > > > segment[0].memsz = 0x1ca
> > > > > segment[1].buf = 0x57498098
> > > > > segment[1].bufsz = 0x200
> > > > > segment[1].mem = 0x1ea
> > > > > segment[1].memsz = 0x4000
> > > > >
> > > > > Signed-off-by: WANG Rui
> > > > > ---
> > > > >
> > > > > v1->v2:
> > > > > * Fix the issue preventing it from working on the physical machine.
> > > > >
> > > > > kexec/arch/loongarch/kexec-loongarch.c | 10 +++---
> > > > > 1 file changed, 7 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/kexec/arch/loongarch/kexec-loongarch.c
> > > > > b/kexec/arch/loongarch/kexec-loongarch.c
> > > > > index 62ff8fd..32a42d2 100644
> > > > > --- a/kexec/arch/loongarch/kexec-loongarch.c
> > > > > +++ b/kexec/arch/loongarch/kexec-loongarch.c
> > > > > @@ -265,9 +265,13 @@ unsigned long
> > > > > loongarch_locate_kernel_segment(struct kexec_info *info)
> > > > > hole = ULONG_MAX;
> > > > > }
> > > > > } else {
> > > > > - hole = locate_hole(info,
> > > > > - loongarch_mem.text_offset +
> > > > > loongarch_mem.image_size,
> > > > > - MiB(1), 0, ULONG_MAX, 1);
> > > > > + unsigned long hole_min;
> > > > > + unsigned long hole_max;
> > > > > +
> > > > > + hole_min = loongarch_mem.text_offset;
> > > > > + hole_max = hole_min + loongarch_mem.image_size;
> > > > > + hole = locate_hole(info, loongarch_mem.image_size,
> > > > > + MiB(1), hole_min, hole_max, 1);
> > > > >
> > > > > if (hole == ULONG_MAX)
> > > > > dbgprintf("%s: locate_hole failed\n",
> > > > > __func__);
> > > >
> > > > Hi,
> > > >
> > > > Previously when I played with the zboot kernel on a kvm guest I
> > > > noticed this issue, but I found that the 1st 2M memory is memblock
> > > > reserved but it is not shown in /proc/iomem as reserved, I suspect the
> > > > 1st 2M is not usable for some arch specific reason but I was not sure.
> > > > Below patch can fix it but due to my rusty knowledge of loongarch I
> > >
> > > Correct about my English wording a bit, I meant about rusty knowledge
> > > of kexec details and newbish loongarch knowledge,
> > > BTW, the webmail often randomly choose the sender email, I usually use
> > > another email for community, that is Dave Young ,
> > > same person ;)
> > >
> > > Anyway, since this is loongarch specific, it would be better to leave
> > > you guys the arch people to see how to fix it better.
> > >
> > > > did not send it out. I suspect even if the locate_hole avoids the
> > > > wrong memory, in the 2nd kernel it could
Re: [PATCH] LoongArch: Fix an issue with relocatable vmlinux
On Fri, Nov 24, 2023 at 04:54:10PM +0800, WANG Rui wrote: > Normally vmlinux for LoongArch is of ET_EXEC type, while if built with > CONFIG_RELOCATABLE (this is PIE) and Clang, it will be of ET_DYN type. > Meanwhile, physical address field of segments in vmlinux has actually > the same value as virtual address field. > > Similar to arm64, this patch allows to unconditionally skip the check > on LoongArch. > > Link: https://github.com/ClangBuiltLinux/linux/issues/1963 > Signed-off-by: WANG Rui Thanks, applied. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] m68k: fix getrandom() use with uclibc
On Sat, Apr 22, 2023 at 11:59:04AM +0200, Laurent Vivier wrote:
> With uclibc, getrandom() is only defined with _GNU_SOURCE, fix that:
>
> kexec/arch/m68k/bootinfo.c: In function 'bootinfo_add_rng_seed':
> kexec/arch/m68k/bootinfo.c:231:13: warning: implicit declaration of function
> 'getrandom'; did you mean 'srandom'? [-Wimplicit-function-declaration]
> 231 | if (getrandom(bi->rng_seed.data, RNG_SEED_LEN, GRND_NONBLOCK)
> != RNG_SEED_LEN) {
> | ^
> | srandom
> kexec/arch/m68k/bootinfo.c:231:56: error: 'GRND_NONBLOCK' undeclared (first
> use in this function)
> 231 | if (getrandom(bi->rng_seed.data, RNG_SEED_LEN, GRND_NONBLOCK)
> != RNG_SEED_LEN) {
> |^
>
> Fixes: b9de05184816 ("m68k: pass rng seed via BI_RNG_SEED")
> Cc: ja...@zx2c4.com
> Signed-off-by: Laurent Vivier
Thanks, applied.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] lzma: Relax memory limit for lzma decompressor
On Sat, Nov 25, 2023 at 03:26:43PM +0800, WANG Rui wrote: > The kexec cannot load LZMA compressed vmlinuz.efi on LoongArch. > > Try LZMA decompression. > lzma_decompress_file: read on /tmp/Image4yyfhM of 65536 bytes failed > pez_prepare: decompressed size 8563960 > pez_prepare: done > Cannot load vmlinuz.efi > > The root cause is that lzma decompressor requires more memory usage, > which exceeds the current 64M limit. > > Reported-by: Huacai Chen > Signed-off-by: WANG Rui Thanks, applied. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] LoongArch: Load vmlinux.efi to the link address
On Fri, Nov 24, 2023 at 11:46:58PM +0800, WANG Rui wrote: > Currently, kexec loads vmlinux.efi to address 0 instead of the link > address. This causes kexec to fail to boot the new vmlinux.efi on qemu. > > pei_loongarch_load: kernel_segment: > pei_loongarch_load: kernel_entry: 015dc000 > pei_loongarch_load: image_size: 01f3 > pei_loongarch_load: text_offset:0020 > pei_loongarch_load: phys_offset: > pei_loongarch_load: PE format: yes > loongarch_load_other_segments:333: command_line: kexec console=ttyS0,115200 > kexec_load: entry = 0x15dc000 flags = 0x102 > nr_segments = 2 > segment[0].buf = 0x7fffef664010 > segment[0].bufsz = 0x1de9a00 > segment[0].mem = (nil) > segment[0].memsz = 0x1f3 > segment[1].buf = 0x55e480b0 > segment[1].bufsz = 0x200 > segment[1].mem = 0x1f3 > segment[1].memsz = 0x4000 > > This patch adds `text_offset` when adding kernel segment to load > vmlinux.efi to the link address. > > pei_loongarch_load: kernel_segment: > pei_loongarch_load: kernel_entry: 015dc000 > pei_loongarch_load: image_size: 01f3 > pei_loongarch_load: text_offset:0020 > pei_loongarch_load: phys_offset: > pei_loongarch_load: PE format: yes > loongarch_load_other_segments:335: command_line: kexec console=ttyS0,115200 > kexec_load: entry = 0x15dc000 flags = 0x102 > nr_segments = 2 > segment[0].buf = 0x71a04010 > segment[0].bufsz = 0x1de9a00 > segment[0].mem = 0x20 > segment[0].memsz = 0x1f3 > segment[1].buf = 0x55b28098 > segment[1].bufsz = 0x200 > segment[1].mem = 0x213 > segment[1].memsz = 0x4000 > > Signed-off-by: WANG Rui Thanks, applied. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] kexec_file: add kexec_file flag to support debug printing
On Tue, Nov 14, 2023 at 11:20:30PM +0800, Baoquan He wrote: > This add KEXEC_FILE_DEBUG to kexec_file_flags so that it can be passed > to kernel when '-d' is added with kexec_file_load interface. With that > flag enabled, kernel can enable the debugging message printing. > > Signed-off-by: Baoquan He Thanks, this looks fine to me. But perhaps the corresponding Kernel patch should land first? Let me know what you think. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] kexec: ppc64: print help to stdout instead of stderr
On Thu, Nov 16, 2023 at 02:11:37PM +0530, Aditya Gupta wrote: > Currently 'kexec --help' on powerpc64 prints the generic help/usage to > stdout, and the powerpc64 specific options to stderr > > That is, if the stdout of 'kexec --help' is redirected to some file, > some of the help options will not be redirected, and instead printed on > the terminal/stderr: > > [root@machine kexec-tools]# kexec --help > /tmp/out > --command-line= command line to append. > --append= same as --command-line. > --ramdisk= Initial RAM disk. > --initrd= same as --ramdisk. > --devicetreeblob= Specify device tree blob file. > Not applicable while using > --kexec-file-syscall. > --dtb= same as --devicetreeblob. > elf support is still broken > --elf64-core-headers Prepare core headers in ELF64 format > --dt-no-old-root Do not reuse old kernel root= param. > while creating flatten device tree. > > Fix this inconsistency by writing powerpc64 specific options to stdout, > similar to the generic 'kexec --help' > > With the proposed changes, it is like this (nothing printed to stderr): > > [root@machine kexec-tools]# ./build/sbin/kexec --help > /tmp/out > > Reported-by: Srikar Dronamraju > Signed-off-by: Aditya Gupta Thanks Aditya, applied. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH kexec-tools] workflow: update to Ubuntu 22.04
On Wed, Oct 11, 2023 at 10:59:33AM +0200, Simon Horman wrote: > Bump workflow to use latest LTS release. > > Signed-off-by: Simon Horman FTR, this has been applied. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH kexec-tools] workflow: update to Ubuntu 22.04
Bump workflow to use latest LTS release. Signed-off-by: Simon Horman --- .github/workflows/build.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml index 4c6e9d730488..d0007f14b274 100644 --- a/.github/workflows/build.yml +++ b/.github/workflows/build.yml @@ -5,7 +5,7 @@ on: push jobs: build: name: Build -runs-on: ubuntu-20.04 +runs-on: ubuntu-22.04 strategy: matrix: arch: -- 2.30.2 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] kexec/loongarch64: fix 'make dist' file loss issue
On Wed, Oct 11, 2023 at 11:56:21AM +0800, Ming Wang wrote: > The Makefile omits the iomem.h file, causing the archive file > generated by 'make dist' to lose iomem.h. This patch is used to > fix this problem. > > Signed-off-by: Ming Wang Thanks, applied. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [kexec-tools] Archive file is missed iomem.h file under loongarch architecture.
On Mon, Oct 09, 2023 at 05:47:43PM +0800, Ming Wang wrote: > Hi, maintainers, > > > I get the kexec-tools 2.0.27 from > http://kernel.org/pub/linux/utils/kernel/kexec/kexec-tools-2.0.27.tar.gz, > > But I noticed that the kexec-tools-2.0.27/kexec/arch/loongarch/iomem.h file > was missing from > > this archive. > > > This causes build errors in many distributions, like debian. The error > message is as follows, > > make[1]: *** [Makefile:123: kexec/arch/loongarch/crashdump-loongarch.o] Error > 1 > kexec/arch/loongarch/kexec-loongarch.c:27:10: fatal error: iomem.h: No such > file or directory >27 | #include "iomem.h" > > See also: https://buildd.debian.org/status/package.php?p=kexec-tools=sid > > > Can this archive be repaired and updated? > > > Thanks, Ming Hi, I need to think about how to deal with this from a release PoV. But can you check if the patch below resolves your problem? diff --git a/kexec/arch/loongarch/Makefile b/kexec/arch/loongarch/Makefile index cee7e569a2a2..f91d0baf049a 100644 --- a/kexec/arch/loongarch/Makefile +++ b/kexec/arch/loongarch/Makefile @@ -19,5 +19,6 @@ loongarch_VIRT_TO_PHYS = dist += kexec/arch/loongarch/Makefile $(loongarch_KEXEC_SRCS) \ kexec/arch/loongarch/kexec-loongarch.h \ kexec/arch/loongarch/image-header.h \ + kexec/arch/loongarch/iomem.h \ kexec/arch/loongarch/crashdump-loongarch.h \ kexec/arch/loongarch/include/arch/options.h ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 1/1] kexec: provide a memfd_create() wrapper if not present in libc
On Sat, Sep 23, 2023 at 06:46:06PM +0200, Julien Olivain wrote:
> Commit 714fa115 "kexec/arm64: Simplify the code for zImage" introduced
> a use of the memfd_create() system call, included in version
> kexec-tools v2.0.27.
>
> This system call was introduced in kernel commit [1], first included
> in kernel v3.17 (released on 2014-10-05).
>
> The memfd_create() glibc wrapper function was added much later in
> commit [2], first included in glibc version 2.27 (released on
> 2018-02-01).
>
> This direct use memfd_create() introduced a requirement on
> Kernel >= 3.17 and glibc >= 2.27.
>
> There is old toolchains like [3] for example (which ships gcc 7.3.1,
> glibc 2.25 and includes kernel v4.10 headers), that can still be used
> to build newer kernels. Even if such toolchains can be seen as
> outdated, they are is still claimed as supported by recent kernel.
> For example, Kernel v6.5.5 has a requirement on gcc version 5.1 and
> greater. See [4].
>
> Moreover, kexec-tools <= 2.0.26 could be compiled using recent
> toolchains with alternative libc (e.g. uclibc-ng, musl) which are not
> providing the memfd_create() wrapper.
>
> When compiling kexec-tools v2.0.27 with a toolchain not providing the
> memfd_create() syscall wrapper, the compilation fail with message:
>
> kexec/kexec.c: In function 'copybuf_memfd':
> kexec/kexec.c:645:7: warning: implicit declaration of function
> 'memfd_create'; did you mean 'SYS_memfd_create'?
> [-Wimplicit-function-declaration]
> fd = memfd_create("kernel", MFD_ALLOW_SEALING);
>^~~~
>SYS_memfd_create
> kexec/kexec.c:645:30: error: 'MFD_ALLOW_SEALING' undeclared (first use in
> this function); did you mean '_PC_ALLOC_SIZE_MIN'?
> fd = memfd_create("kernel", MFD_ALLOW_SEALING);
> ^
> _PC_ALLOC_SIZE_MIN
>
> In order to let kexec-tools compile in a wider range of configurations,
> this commit adds a memfd_create() function check in autoconf configure
> script, and adds a system call wrapper which will be used if the
> function is not available. With this commit, the environment
> requirement is relaxed to only kernel >= v3.17.
>
> Note: this issue was found in kexec-tools integration in Buildroot [5]
> using the command "utils/test-pkg -a -p kexec", which tests many
> toolchain/arch combinations.
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9183df25fe7b194563db3fec6dc3202a5855839c
> [2]
> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=59d2cbb1fe4b8601d5cbd359c3806973eab6c62d
> [3]
> https://releases.linaro.org/components/toolchain/binaries/7.3-2018.05/aarch64-linux-gnu/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu.tar.xz
> [4]
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/process/changes.rst?h=v6.5.5#n32
> [5] https://buildroot.org/
>
> Signed-off-by: Julien Olivain
Thanks Julien,
applied.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v3 0/6] crashdump: Kernel handling of CPU and memory hot un/plug
On Wed, Sep 27, 2023 at 02:11:30PM -0400, Eric DeVolder wrote: > When the kdump service is loaded, if a CPU or memory is hot > un/plugged, the crash elfcorehdr, which describes the CPUs and memory > in the system, must also be updated, else the resulting vmcore is > inaccurate (eg. missing either CPU context or memory regions). > > The current solution utilizes udev (eg. RHEL /usr/lib/udev/rules.d/ > 98-kexec.rules) to initiate an unload-then-reload of the *entire* kdump > image (eg. kernel, initrd, boot_params, purgatory and elfcorehdr) by > the userspace kexec utility. This occurrs just so the elfcorehdr can > be updated with the latest list of CPUs and memory regions. In a > previous post I have outlined the significant performance problems > related to offloading this activity to userspace. > > With the Linux kernel 6.6 commit below, the kernel now has the ability > to directly modify the elfcorehdr, eliminating the need to > unload-then-reload the entire kdump image when CPU or memory is hot > un/plugged or on/offlined. > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6 > 8b4b6f307d155475cce541f2aee938032ed22e > > This kexec-tools patch series is for supporting hotplug with the > kexec_load() syscall; the kernel directly supports hotplug for the > kexec_file_load() syscall, requiring no userspace help. > > There are two basic obstacles/requirements for the kexec-tools to > overcome in order to support kernel hotplug rewriting of the > elfcorehdr. > > First, the buffer containing the elfcorehdr must be excluded from the > purgatory checksum/digest, which is computed at load time. Otherwise > kernel run-time changes to the elfcorehdr, as a result of hot un/plug, > would result in the checksum failing (specifically in purgatory at > panic kernel boot time), and kdump capture kernel failing to start. > To let the kernel know it is okay to modify the elfcorehdr, kexec > sets the KEXEC_UPDATE_ELFCOREHDR flag. > > NOTE: The kernel specifically does *NOT* attempt to recompute the > checksum/digest as that would ultimately require patching the in- > memory purgatory image with the updated checksum. As that purgatory > image is already fully linked, it is binary blob containing no ELF > information which would allow it to be re-linked or patched. Thus > excluding the elfcorehdr from the checksum/digests avoids all these > problems. > > Second, the size of the elfcorehdr buffer must be large enough > to accomodate growth of the number of CPUs and/or memory regions. > > To satisfy the first requirement, this patch series introduces the > --hotplug option to indicate to kexec-tools that kexec should exclude > the elfcorehdr buffer from the purgatory checksum/digest calculation > and set the KEXEC_UPDATE_ELFCOREHDR flag. > > To satisfy the second requirement, the size is obtained from the > /sys/kernel/crash_elfcorehdr_size node (new with the kernel series > cited above). > > To use this feature with kexec_load() syscall, invoke kexec with: > > kexec -c --hotplug ... > > Thanks! > eric Thanks Eric, applied. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] kexec: update manpage with explicit mention of clean kexec
On Wed, Sep 20, 2023 at 05:29:27PM +0530, Hari Bathini wrote: > While the manpage does mention about kexec boot with a clean shutdown, > it is not explicit about it. Make it explicit. > > Signed-off-by: Hari Bathini Thanks, applied. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 0/7] Kexec-tools: Improve RISC-V port
On Fri, Sep 15, 2023 at 11:50:06AM +0800, Song Shuai wrote: > Hi, > > This series is created to improve RISC-V port of kexec-tools, > and is based on the horms/kexec-tools:build-test-riscv-v2 branch. In my mind the big question is how to move RISC-V support from that branch, to being merged into main. IIRC there were some issues that needed to be addressed. Perhaps they are all addressed by this series, and with some appropriate squashing we can move forwards with a series based on main? > > For your convenience, here is my Github branch for kexec-tools: > https://github.com/sugarfillet/kexec-tools/commits/rv-Image > > The first four patches fixes some build or runtime issues: > > RISC-V: Use linux,usable-memory-range for crash kernel > RISC-V: Fix the undeclared ‘EM_RISCV’ build failure > RISC-V: Get memory ranges from iomem > RISC-V: Correct the usage of command line option > > The last three patches enable the kexec_file_load syscall to load > vmlinux and support loading Image binary file for two syscalls. > > RISC-V: Enable kexe_file_load > RISC-V: Separate elf_riscv_find_pbase out > RISC-V: Support loading Image binary file > > Note that: > > RISC-V Linux kexec_load_file's support for Image file has been sent out but > not merged [1]. > > [1]: > https://lore.kernel.org/linux-riscv/20230914020044.1397356-1-songshuaish...@tinylab.org/T/#t > > > Li Zhengyu (1): > RISC-V: Enable kexe_file_load > > Song Shuai (6): > RISC-V: Use linux,usable-memory-range for crash kernel > RISC-V: Fix the undeclared ‘EM_RISCV’ build failure > RISC-V: Get memory ranges from iomem > RISC-V: Correct the usage of command line option > RISC-V: Separate elf_riscv_find_pbase out > RISC-V: Support loading Image binary file > > kexec/arch/riscv/Makefile| 2 + > kexec/arch/riscv/crashdump-riscv.c | 2 +- > kexec/arch/riscv/image-header.h | 88 ++ > kexec/arch/riscv/iomem.h | 10 ++ > kexec/arch/riscv/kexec-elf-riscv.c | 77 +--- > kexec/arch/riscv/kexec-image-riscv.c | 95 +++ > kexec/arch/riscv/kexec-riscv.c | 176 ++- > kexec/arch/riscv/kexec-riscv.h | 21 > kexec/kexec-syscall.h| 3 + > 9 files changed, 368 insertions(+), 106 deletions(-) > create mode 100644 kexec/arch/riscv/image-header.h > create mode 100644 kexec/arch/riscv/iomem.h > create mode 100644 kexec/arch/riscv/kexec-image-riscv.c > > -- > 2.20.1 > ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH -next] crash_core: Remove duplicated include in crash_core.c
On Fri, Sep 15, 2023 at 01:58:44PM +0800, Yang Li wrote:
> ./kernel/crash_core.c: linux/kexec.h is included more than once.
>
> Signed-off-by: Yang Li
FWIIW, this seems to have been added recently, by
926f75c8a5ab ("Add linux-next specific files for 20230920")
Reviewed-by: Simon Horman
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v1 0/2] zboot: enable kexec_load for zboot kernel images
On Thu, Sep 14, 2023 at 04:49:58PM +0800, Dave Young wrote: > The current kexec-tools only support kexec_file_load for zboot kernel > images on arm64. > > This series tweak a bit of the code so kexec_load can also load zboot > images on both arm64 and loongarch. Thanks, applied. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] kexec: update manpage with explicit mention of clean kexec
On Mon, Sep 11, 2023 at 12:04:08PM +0530, Hari Bathini wrote: > > > On 28/08/23 3:12 pm, Baoquan He wrote: > > On 08/28/23 at 09:48am, Simon Horman wrote: > > > On Mon, Aug 28, 2023 at 11:46:14AM +0530, Hari Bathini wrote: > > > > Any comments on this, please.. > > > > > > Hi Hari, > > > > > > Sorry, I had missed this. > > > > > > > On 07/07/23 10:59 am, Hari Bathini wrote: > > > > > While the manpage does mention about kexec boot with a clean shutdown, > > > > > it is not explicit about it. Make it explicit. > > > > > > > > > > Signed-off-by: Hari Bathini > > > > > --- > > > > >kexec/kexec.8 | 12 ++-- > > > > >1 file changed, 10 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/kexec/kexec.8 b/kexec/kexec.8 > > > > > index 3a344c5..87e4ab5 100644 > > > > > --- a/kexec/kexec.8 > > > > > +++ b/kexec/kexec.8 > > > > > @@ -95,8 +95,16 @@ then you would use the following command to load > > > > > the kernel: > > > > >.RB "\-\-append=" "root=/dev/hda1" "\ \-\-initrd=" /boot/initrd > > > > >.RE > > > > >.PP > > > > > -After this kernel is loaded, it can be booted to at any time using > > > > > the > > > > > -command: > > > > > +After this kernel is loaded, assuming your Linux distribution > > > > > supports > > > > > +kexec-based rebooting, it can be booted to, with a clean shutdown, > > > > > using > > > > > +the command: > > > > > > Perhaps user-space would be better than "your Linux distribution". > > > But perhaps that is just kernel developer speak and makes less > > > sense to others. > > > > Agree, linux distrobution doesn't make sense here. And since this is a > > kexec man page, does it really need to make this change? We know > > kexec-tools loaded a kernel, we will use kexec-tools to trigger the > > reboot. Wondering why we need to stress distros or kernel or kexec-tools > > supports the kexec-based rebooting. 'with a clean shutdown' seems a > > little helpful though. > > Yeah. Users did express that lack of clarity on what is the cleaner > approach to use kexec boot after load. That prompted this patch. > I am ok with "user-space" or "your linux distribution". > > Simon, do you want to respin with "user-space" change instead? Yes, I think that would be best. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [kexec-tools PATCH] build: fix tarball creation
On Mon, Aug 28, 2023 at 11:58:15AM +0200, Leah Neukirchen wrote: > The fix in 41b77edac did not work, bsdtar still complains about > "hardlink pointing to itself". > > Simplify the code instead: since the staging directory contains > exactly the files we want, just package it as a whole. > > Signed-off-by: Leah Neukirchen Thanks, applied. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[ANNOUNCE] kexec-tools 2.0.27
Hi all, I am happy to announce the release of kexec-tools 2.0.27. This is a feature release coinciding with the release of v6.5 of the Linux Kernel. This release can be downloaded from kernel.org: http://kernel.org/pub/linux/utils/kernel/kexec/kexec-tools-2.0.27.tar.xz http://kernel.org/pub/linux/utils/kernel/kexec/ It is also tagged it in git: git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git Thanks to everyone who has contributed to kexec! Commits since v2.0.26: 17590eedff6d kexec-tools 2.0.27 777ca453ca69 kexec-tools 2.0.27-rc1 f67c4146d7b5 arm64: Hook up the ZBOOT support as vmlinuz fc7b83bdf734 arm64: Add ZBOOT PE containing compressed image support f41c4182b0c4 kexec/zboot: Add arch independent zboot support 1572b91da7c4 kexec: Introduce a member kernel_fd in kexec_info 714fa11590fe kexec/arm64: Simplify the code for zImage a8de94e5f033 LoongArch: kdump: Set up kernel image segment 4203eaccfa92 kexec: __NR_kexec_file_load is set to undefined on LoongArch 63e9a012112e ppc64: Add elf-ppc64 file types/options and an arch specific flag to man page 806711fca9e9 x86: add devicetree support 29fe5067ed07 kexec: make -a the default e63fefd4fc35 ppc64: add --reuse-cmdline parameter support 8fc55927f700 kexec-tools 2.0.26.git ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] kexec: update manpage with explicit mention of clean kexec
On Mon, Aug 28, 2023 at 11:46:14AM +0530, Hari Bathini wrote: > Any comments on this, please.. Hi Hari, Sorry, I had missed this. > On 07/07/23 10:59 am, Hari Bathini wrote: > > While the manpage does mention about kexec boot with a clean shutdown, > > it is not explicit about it. Make it explicit. > > > > Signed-off-by: Hari Bathini > > --- > > kexec/kexec.8 | 12 ++-- > > 1 file changed, 10 insertions(+), 2 deletions(-) > > > > diff --git a/kexec/kexec.8 b/kexec/kexec.8 > > index 3a344c5..87e4ab5 100644 > > --- a/kexec/kexec.8 > > +++ b/kexec/kexec.8 > > @@ -95,8 +95,16 @@ then you would use the following command to load the > > kernel: > > .RB "\-\-append=" "root=/dev/hda1" "\ \-\-initrd=" /boot/initrd > > .RE > > .PP > > -After this kernel is loaded, it can be booted to at any time using the > > -command: > > +After this kernel is loaded, assuming your Linux distribution supports > > +kexec-based rebooting, it can be booted to, with a clean shutdown, using > > +the command: Perhaps user-space would be better than "your Linux distribution". But perhaps that is just kernel developer speak and makes less sense to others. > > + > > +.RS > > +.BR reboot > > +.RE > > +.PP > > +Alternatively, it can also be booted to, without calling shutdown(8), with > > +the command: > > > > .RS > > .BR kexec \ \-e > ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[ANNOUNCE] kexec-tools 2.0.27-rc1
Hi all, I am happy to announce the release of kexec-tools 2.0.27-rc1. This is an incremental feature pre-release. So long as no serious problems arise I intend to release kexec-tools 2.0.27 in a weeks time. Testing of 2.0.27-rc1 would be greatly appreciated. I do not have any outstanding changes for 2.0.27 at this time. And I would like to only accept bug fixes at this time and take features patches once 2.0.27 has been released. The pre-release can be downloaded from kernel.org: https://kernel.org/pub/linux/utils/kernel/kexec/kexec-tools-2.0.27-rc1.tar.xz https://kernel.org/pub/linux/utils/kernel/kexec/ I have also tagged it in git: https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git Thanks to everyone who has contributed to kexec. For reference the changes since v2.0.26 are: 777ca453ca69 kexec-tools 2.0.27-rc1 f67c4146d7b5 arm64: Hook up the ZBOOT support as vmlinuz fc7b83bdf734 arm64: Add ZBOOT PE containing compressed image support f41c4182b0c4 kexec/zboot: Add arch independent zboot support 1572b91da7c4 kexec: Introduce a member kernel_fd in kexec_info 714fa11590fe kexec/arm64: Simplify the code for zImage a8de94e5f033 LoongArch: kdump: Set up kernel image segment 4203eaccfa92 kexec: __NR_kexec_file_load is set to undefined on LoongArch 63e9a012112e ppc64: Add elf-ppc64 file types/options and an arch specific flag to man page 806711fca9e9 x86: add devicetree support 29fe5067ed07 kexec: make -a the default e63fefd4fc35 ppc64: add --reuse-cmdline parameter support 8fc55927f700 kexec-tools 2.0.26.git ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [ANNOUNCE] kexec-tools v2.0.27 preparation
On Mon, Aug 14, 2023 at 11:19:07AM +0800, Coiby Xu wrote: > Hi Sourabh, > > On Mon, Aug 14, 2023 at 08:17:34AM +0530, Sourabh Jain wrote: > > Hello Simon, > > > > Can we include below fix? > > https://lists.fedoraproject.org/archives/list/ke...@lists.fedoraproject.org/thread/O3W4SLVVFT6J25U5YSXNZ3URZ4QY6SRU/ > > I'll review your patch! Note the patch is against Fedora's kexec-tools > so it doesn't apply to this upstream kexec-tools. The relationship > between Fedora's kexec-tools and this upstream kexec-tools can be > described as follows, > 1. Fedora's kexec-tools packages the kexec binary which is provides by > upstream > kexec-tools; 2. The kexec binary is used for loading the kdump kernel and > initrd but > it's not responsible for building the kdump initrd. Fedora's kexec-tools > is used to build the kdump initrd instead. > > Currrently it's WIP to split current Fedora kexec-tools into > kexec-tools, kdump-utils, makedumpfile and eppic. Hopefully after it's > done, you and other uses will no longer be confused by the relationship > between Fedora's kexec-tools and this upstream kexec-tools. Thanks for the clarification, I'm assuming no action is needed on my part at this time. Let me know if I am mistaken. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[ANNOUNCE] kexec-tools v2.0.27 preparation
Hi all, I am planning to release kexec-tools v2.0.27 in the next two weeks to roughly coincide with the release of the v6.5 kernel. I would like to ask interested parties to send any patches they would like included in v2.0.27 within one week so they can be considered for inclusion in an rc release. For reference the patches queued up since v2.0.26 are as follows. Thanks to everyone who has contributed to kexec-tools! f67c4146d7b5 arm64: Hook up the ZBOOT support as vmlinuz fc7b83bdf734 arm64: Add ZBOOT PE containing compressed image support f41c4182b0c4 kexec/zboot: Add arch independent zboot support 1572b91da7c4 kexec: Introduce a member kernel_fd in kexec_info 714fa11590fe kexec/arm64: Simplify the code for zImage a8de94e5f033 LoongArch: kdump: Set up kernel image segment 4203eaccfa92 kexec: __NR_kexec_file_load is set to undefined on LoongArch 63e9a012112e ppc64: Add elf-ppc64 file types/options and an arch specific flag to man page 806711fca9e9 x86: add devicetree support 29fe5067ed07 kexec: make -a the default e63fefd4fc35 ppc64: add --reuse-cmdline parameter support 8fc55927f700 kexec-tools 2.0.26.git ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCHv7 0/5] arm64: zboot support
On Thu, Aug 03, 2023 at 10:41:47AM +0800, Pingfan Liu wrote: > From: root > > As more complicated capsule kernel format occurs like zboot, where the > compressed kernel is stored as a payload. The straight forward > decompression can not meet the demand. > > As the first step, on aarch64, reading in the kernel file in a probe > method and decide how to unfold the content by the method itself. > > This series consists of two parts > [1/5], simplify the current aarch64 image probe > [2-5/5], return the kernel fd by the image load interface, and let the > handling of zboot image built on it. (Thanks for Dave Young, who > contributes the original idea and the code) > > > To ease the review, a branch is also available at > https://github.com/pfliu/kexec-tools.git > branch zbootV7 > > To: kexec@lists.infradead.org > Cc: Dave Young > Cc: ho...@verge.net.au > Cc: a...@kernel.org > Cc: jeremy.lin...@arm.com Thanks everyone, applied. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCHv7 1/5] kexec/arm64: Simplify the code for zImage
On Mon, Aug 07, 2023 at 09:26:49PM +0800, Dave Young wrote: > On Mon, 7 Aug 2023 at 21:23, Simon Horman wrote: > > > > On Thu, Aug 03, 2023 at 10:41:48AM +0800, Pingfan Liu wrote: > > > Inside zimage_probe(), it uncompresses the kernel and performs some > > > check, similar to image_probe(). Taking a close look, the uncompressing > > > has already executed before the image probe is called. What is missing > > > here is to provide a fd, pointing to an uncompressed kernel image. > > > > > > This patch creates a memfd based on the result produced by > > > slurp_decompress_file(), and finally simplify the logical of the probe > > > for aarch64. > > > > > > The credit goes to the Dave Young, who contributes the original code. > > > > > > Signed-off-by: Pingfan Liu > > > Co-authored-by: Dave Young > > > > Dave, could I get a Signed-off-by line from you? > > Likewise for patch 2/5. > > I Simon, sounds good to me, thanks! Thanks, could your respond to the two patches with the following? Signed-off by: <> > > > > > I think simply replying to the relevant emails should be sufficient. > > > > ___ > > kexec mailing list > > kexec@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/kexec > > > ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCHv7 3/5] kexec/zboot: Add arch independent zboot support
On Thu, Aug 03, 2023 at 10:41:50AM +0800, Pingfan Liu wrote:
> From: Jeremy Linton
>
> The linux kernel CONFIG_ZBOOT option creates
> self decompressing PE kernel images. So this means
> that kexec should have a generic understanding of
> the format which may be used by multiple arches.
>
> So lets add an arch independent validation
> and decompression routine.
>
> Signed-off-by: Jeremy Linton
> [Modified by Pingfan to export kernel fd]
> Signed-off-by: Pingfan Liu
> To: kexec@lists.infradead.org
> Cc: ho...@verge.net.au
> Cc: a...@kernel.org
> Cc: jeremy.lin...@arm.com
> ---
> include/Makefile | 1 +
> include/kexec-pe-zboot.h | 15 +
> kexec/Makefile | 1 +
> kexec/kexec-pe-zboot.c | 131 +++
> 4 files changed, 148 insertions(+)
> create mode 100644 include/kexec-pe-zboot.h
> create mode 100644 kexec/kexec-pe-zboot.c
>
> diff --git a/include/Makefile b/include/Makefile
> index 621ce9f..cd88a26 100644
> --- a/include/Makefile
> +++ b/include/Makefile
> @@ -1,6 +1,7 @@
> dist += include/Makefile \
> include/config.h\
> include/config.h.in \
> + include/kexec-pe-zboot.h\
> include/kexec-uImage.h \
> include/x86/x86-linux.h \
> include/x86/mb_info.h \
> diff --git a/include/kexec-pe-zboot.h b/include/kexec-pe-zboot.h
> new file mode 100644
> index 000..c588ca2
> --- /dev/null
> +++ b/include/kexec-pe-zboot.h
> @@ -0,0 +1,15 @@
> +#ifndef __KEXEC_PE_ZBOOT_H__
> +#define __KEXEC_PE_ZBOOT_H__
> +
> +/* see drivers/firmware/efi/libstub/zboot-header.S */
> +struct linux_pe_zboot_header {
> + uint32_t mz_magic;
> +uint32_t image_type;
> +uint32_t payload_offset;
> +uint32_t payload_size;
> +uint32_t reserved[2];
> +uint32_t compress_type;
> +};
nit: the above should consistently use tabs for indentation.
I can try and fix this when applying if there is no v8.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCHv7 1/5] kexec/arm64: Simplify the code for zImage
On Thu, Aug 03, 2023 at 10:41:48AM +0800, Pingfan Liu wrote: > Inside zimage_probe(), it uncompresses the kernel and performs some > check, similar to image_probe(). Taking a close look, the uncompressing > has already executed before the image probe is called. What is missing > here is to provide a fd, pointing to an uncompressed kernel image. > > This patch creates a memfd based on the result produced by > slurp_decompress_file(), and finally simplify the logical of the probe > for aarch64. > > The credit goes to the Dave Young, who contributes the original code. > > Signed-off-by: Pingfan Liu > Co-authored-by: Dave Young Dave, could I get a Signed-off-by line from you? Likewise for patch 2/5. I think simply replying to the relevant emails should be sufficient. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCHv6 3/5] kexec/zboot: Add arch independent zboot support
On Thu, Aug 03, 2023 at 10:37:10AM +0800, Pingfan Liu wrote: > On Wed, Aug 2, 2023 at 8:33 PM Simon Horman wrote: > > > > On Wed, Aug 02, 2023 at 02:17:57PM +0200, Simon Horman wrote: > > > On Wed, Aug 02, 2023 at 02:16:33PM +0200, Simon Horman wrote: > > > > On Wed, Aug 02, 2023 at 05:53:59PM +0800, Pingfan Liu wrote: > > > > > Hi Simon, > > > > > > > > > > Thanks for the try. Please see the comment below. > > > > > > > > > > On Tue, Aug 1, 2023 at 3:00 PM Simon Horman wrote: > > > > > > > > > > > > On Mon, Jul 24, 2023 at 10:21:40AM +0800, Pingfan Liu wrote: > > > > > > > From: Jeremy Linton > > > > > > > > > > > > > > The linux kernel CONFIG_ZBOOT option creates > > > > > > > self decompressing PE kernel images. So this means > > > > > > > that kexec should have a generic understanding of > > > > > > > the format which may be used by multiple arches. > > > > > > > > > > > > > > So lets add an arch independent validation > > > > > > > and decompression routine. > > > > > > > > > > > > > > Signed-off-by: Jeremy Linton > > > > > > > [Modified by Pingfan to export kernel fd] > > > > > > > Signed-off-by: Pingfan Liu > > > > > > > > > > > > Hi Pingfan, > > > > > > > > > > > > unfortunately this causes a build failure on hppa. > > > > > > > > > > > > ../../kexec/kexec-pe-zboot.c:31:10: fatal error: kexec-pe-zboot.h: > > > > > > No such file or directory > > > > > >31 | #include > > > > > > | ^~ > > > > > > > > > > > > Link: > > > > > > https://github.com/horms/kexec-tools/actions/runs/5723580523/job/15508425790 > > > > > > > > > > > > > > > > It is not related to cross-compiling. Actually, I have tried to > > > > > simplify the test matrix, which limits the compilation only on x86_64. > > > > > And I got the similar error [1] > > > > > > > > > > The workflow control file is [2], which clips out all arches except > > > > > x86_64. But I can successfully build it on the Fedora system with the > > > > > following bash script, which is based on the github's build log. So > > > > > maybe it is a bug with the compiling tools? > > > > > > > > > > kexec_tools_dir="./" > > > > > > > > > > mkdir $kexec_tools_dir/_build \ > > > > > $kexec_tools_dir/_build/sub \ > > > > > $kexec_tools_dir/_inst \ > > > > > $kexec_tools_dir/_dest > > > > > chmod a-w $kexec_tools_dir > > > > > test -d $kexec_tools_dir/_build > > > > > INSTALL_BASE=$(cd $kexec_tools_dir/_inst && pwd | sed -e > > > > > 's,^[^:\\/]:[\\/],/,') &&\ > > > > > DESTDIR="$kexec_tools_dir/_dest" && \ > > > > > cd $kexec_tools_dir/_build/sub && \ > > > > > ../../configure \ > > > > > \ > > > > > --srcdir=../.. --prefix="$INSTALL_BASE" && \ > > > > > make -j8 > > > > > > > > > > > > > > > [1]: > > > > > https://github.com/pfliu/kexec-tools/actions/runs/5737254109/job/15548520863 > > > > > [2]: > > > > > https://github.com/pfliu/kexec-tools/blob/zbootV6/.github/workflows/main.yml > > > > > > > > Thanks, > > > > > > > > I guess that kexec-pe-zboot.h is missing in the build environment for > > > > the > > > > GitHub actions, but present in your Fedora environment. > > > > > > > > Could you take a look and see where your copy of kexec-pe-zboot.h > > > > came from? > > > > > > Actually it seems to be added by this patch (sorry for not noticing)! > > > So I guess it is an include path problem. > > > > I think I have found the problem. > > The kexec-tools build system is a bit unusual, > > and the new file, kexec-pe-zboot.h, was not included in distribution > > tarballs. Thus the build failures. > > > > Unexpectedly, and thank for your insight. > > > I think you can resolve that by squashing the following into this patch. > > > > diff --git a/include/Makefile b/include/Makefile > > --- a/include/Makefile > > +++ b/include/Makefile > > @@ -1,6 +1,7 @@ > > dist += include/Makefile \ > > include/config.h\ > > include/config.h.in \ > > + include/kexec-pe-zboot.h\ > > include/kexec-uImage.h \ > > include/x86/x86-linux.h \ > > include/x86/mb_info.h \ > > > > After applying this patch, the github workflow successfully finished. > I will send out V7 immediately. > > Appreciate for your kind help again. Thanks, I see v7 now. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCHv6 3/5] kexec/zboot: Add arch independent zboot support
On Wed, Aug 02, 2023 at 02:17:57PM +0200, Simon Horman wrote: > On Wed, Aug 02, 2023 at 02:16:33PM +0200, Simon Horman wrote: > > On Wed, Aug 02, 2023 at 05:53:59PM +0800, Pingfan Liu wrote: > > > Hi Simon, > > > > > > Thanks for the try. Please see the comment below. > > > > > > On Tue, Aug 1, 2023 at 3:00 PM Simon Horman wrote: > > > > > > > > On Mon, Jul 24, 2023 at 10:21:40AM +0800, Pingfan Liu wrote: > > > > > From: Jeremy Linton > > > > > > > > > > The linux kernel CONFIG_ZBOOT option creates > > > > > self decompressing PE kernel images. So this means > > > > > that kexec should have a generic understanding of > > > > > the format which may be used by multiple arches. > > > > > > > > > > So lets add an arch independent validation > > > > > and decompression routine. > > > > > > > > > > Signed-off-by: Jeremy Linton > > > > > [Modified by Pingfan to export kernel fd] > > > > > Signed-off-by: Pingfan Liu > > > > > > > > Hi Pingfan, > > > > > > > > unfortunately this causes a build failure on hppa. > > > > > > > > ../../kexec/kexec-pe-zboot.c:31:10: fatal error: kexec-pe-zboot.h: No > > > > such file or directory > > > >31 | #include > > > > | ^~ > > > > > > > > Link: > > > > https://github.com/horms/kexec-tools/actions/runs/5723580523/job/15508425790 > > > > > > > > > > It is not related to cross-compiling. Actually, I have tried to > > > simplify the test matrix, which limits the compilation only on x86_64. > > > And I got the similar error [1] > > > > > > The workflow control file is [2], which clips out all arches except > > > x86_64. But I can successfully build it on the Fedora system with the > > > following bash script, which is based on the github's build log. So > > > maybe it is a bug with the compiling tools? > > > > > > kexec_tools_dir="./" > > > > > > mkdir $kexec_tools_dir/_build \ > > > $kexec_tools_dir/_build/sub \ > > > $kexec_tools_dir/_inst \ > > > $kexec_tools_dir/_dest > > > chmod a-w $kexec_tools_dir > > > test -d $kexec_tools_dir/_build > > > INSTALL_BASE=$(cd $kexec_tools_dir/_inst && pwd | sed -e > > > 's,^[^:\\/]:[\\/],/,') &&\ > > > DESTDIR="$kexec_tools_dir/_dest" && \ > > > cd $kexec_tools_dir/_build/sub && \ > > > ../../configure \ > > > \ > > > --srcdir=../.. --prefix="$INSTALL_BASE" && \ > > > make -j8 > > > > > > > > > [1]: > > > https://github.com/pfliu/kexec-tools/actions/runs/5737254109/job/15548520863 > > > [2]: > > > https://github.com/pfliu/kexec-tools/blob/zbootV6/.github/workflows/main.yml > > > > Thanks, > > > > I guess that kexec-pe-zboot.h is missing in the build environment for the > > GitHub actions, but present in your Fedora environment. > > > > Could you take a look and see where your copy of kexec-pe-zboot.h > > came from? > > Actually it seems to be added by this patch (sorry for not noticing)! > So I guess it is an include path problem. I think I have found the problem. The kexec-tools build system is a bit unusual, and the new file, kexec-pe-zboot.h, was not included in distribution tarballs. Thus the build failures. I think you can resolve that by squashing the following into this patch. diff --git a/include/Makefile b/include/Makefile --- a/include/Makefile +++ b/include/Makefile @@ -1,6 +1,7 @@ dist += include/Makefile \ include/config.h\ include/config.h.in \ + include/kexec-pe-zboot.h\ include/kexec-uImage.h \ include/x86/x86-linux.h \ include/x86/mb_info.h \ ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCHv6 3/5] kexec/zboot: Add arch independent zboot support
On Wed, Aug 02, 2023 at 02:16:33PM +0200, Simon Horman wrote: > On Wed, Aug 02, 2023 at 05:53:59PM +0800, Pingfan Liu wrote: > > Hi Simon, > > > > Thanks for the try. Please see the comment below. > > > > On Tue, Aug 1, 2023 at 3:00 PM Simon Horman wrote: > > > > > > On Mon, Jul 24, 2023 at 10:21:40AM +0800, Pingfan Liu wrote: > > > > From: Jeremy Linton > > > > > > > > The linux kernel CONFIG_ZBOOT option creates > > > > self decompressing PE kernel images. So this means > > > > that kexec should have a generic understanding of > > > > the format which may be used by multiple arches. > > > > > > > > So lets add an arch independent validation > > > > and decompression routine. > > > > > > > > Signed-off-by: Jeremy Linton > > > > [Modified by Pingfan to export kernel fd] > > > > Signed-off-by: Pingfan Liu > > > > > > Hi Pingfan, > > > > > > unfortunately this causes a build failure on hppa. > > > > > > ../../kexec/kexec-pe-zboot.c:31:10: fatal error: kexec-pe-zboot.h: No > > > such file or directory > > >31 | #include > > > | ^~ > > > > > > Link: > > > https://github.com/horms/kexec-tools/actions/runs/5723580523/job/15508425790 > > > > > > > It is not related to cross-compiling. Actually, I have tried to > > simplify the test matrix, which limits the compilation only on x86_64. > > And I got the similar error [1] > > > > The workflow control file is [2], which clips out all arches except > > x86_64. But I can successfully build it on the Fedora system with the > > following bash script, which is based on the github's build log. So > > maybe it is a bug with the compiling tools? > > > > kexec_tools_dir="./" > > > > mkdir $kexec_tools_dir/_build \ > > $kexec_tools_dir/_build/sub \ > > $kexec_tools_dir/_inst \ > > $kexec_tools_dir/_dest > > chmod a-w $kexec_tools_dir > > test -d $kexec_tools_dir/_build > > INSTALL_BASE=$(cd $kexec_tools_dir/_inst && pwd | sed -e > > 's,^[^:\\/]:[\\/],/,') &&\ > > DESTDIR="$kexec_tools_dir/_dest" && \ > > cd $kexec_tools_dir/_build/sub && \ > > ../../configure \ > > \ > > --srcdir=../.. --prefix="$INSTALL_BASE" && \ > > make -j8 > > > > > > [1]: > > https://github.com/pfliu/kexec-tools/actions/runs/5737254109/job/15548520863 > > [2]: > > https://github.com/pfliu/kexec-tools/blob/zbootV6/.github/workflows/main.yml > > Thanks, > > I guess that kexec-pe-zboot.h is missing in the build environment for the > GitHub actions, but present in your Fedora environment. > > Could you take a look and see where your copy of kexec-pe-zboot.h > came from? Actually it seems to be added by this patch (sorry for not noticing)! So I guess it is an include path problem. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCHv6 3/5] kexec/zboot: Add arch independent zboot support
On Wed, Aug 02, 2023 at 05:53:59PM +0800, Pingfan Liu wrote: > Hi Simon, > > Thanks for the try. Please see the comment below. > > On Tue, Aug 1, 2023 at 3:00 PM Simon Horman wrote: > > > > On Mon, Jul 24, 2023 at 10:21:40AM +0800, Pingfan Liu wrote: > > > From: Jeremy Linton > > > > > > The linux kernel CONFIG_ZBOOT option creates > > > self decompressing PE kernel images. So this means > > > that kexec should have a generic understanding of > > > the format which may be used by multiple arches. > > > > > > So lets add an arch independent validation > > > and decompression routine. > > > > > > Signed-off-by: Jeremy Linton > > > [Modified by Pingfan to export kernel fd] > > > Signed-off-by: Pingfan Liu > > > > Hi Pingfan, > > > > unfortunately this causes a build failure on hppa. > > > > ../../kexec/kexec-pe-zboot.c:31:10: fatal error: kexec-pe-zboot.h: No such > > file or directory > >31 | #include > > | ^~ > > > > Link: > > https://github.com/horms/kexec-tools/actions/runs/5723580523/job/15508425790 > > > > It is not related to cross-compiling. Actually, I have tried to > simplify the test matrix, which limits the compilation only on x86_64. > And I got the similar error [1] > > The workflow control file is [2], which clips out all arches except > x86_64. But I can successfully build it on the Fedora system with the > following bash script, which is based on the github's build log. So > maybe it is a bug with the compiling tools? > > kexec_tools_dir="./" > > mkdir $kexec_tools_dir/_build \ > $kexec_tools_dir/_build/sub \ > $kexec_tools_dir/_inst \ > $kexec_tools_dir/_dest > chmod a-w $kexec_tools_dir > test -d $kexec_tools_dir/_build > INSTALL_BASE=$(cd $kexec_tools_dir/_inst && pwd | sed -e > 's,^[^:\\/]:[\\/],/,') &&\ > DESTDIR="$kexec_tools_dir/_dest" && \ > cd $kexec_tools_dir/_build/sub && \ > ../../configure \ > \ > --srcdir=../.. --prefix="$INSTALL_BASE" && \ > make -j8 > > > [1]: > https://github.com/pfliu/kexec-tools/actions/runs/5737254109/job/15548520863 > [2]: > https://github.com/pfliu/kexec-tools/blob/zbootV6/.github/workflows/main.yml Thanks, I guess that kexec-pe-zboot.h is missing in the build environment for the GitHub actions, but present in your Fedora environment. Could you take a look and see where your copy of kexec-pe-zboot.h came from? ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCHv6 3/5] kexec/zboot: Add arch independent zboot support
On Mon, Jul 24, 2023 at 10:21:40AM +0800, Pingfan Liu wrote: > From: Jeremy Linton > > The linux kernel CONFIG_ZBOOT option creates > self decompressing PE kernel images. So this means > that kexec should have a generic understanding of > the format which may be used by multiple arches. > > So lets add an arch independent validation > and decompression routine. > > Signed-off-by: Jeremy Linton > [Modified by Pingfan to export kernel fd] > Signed-off-by: Pingfan Liu Hi Pingfan, unfortunately this causes a build failure on hppa. ../../kexec/kexec-pe-zboot.c:31:10: fatal error: kexec-pe-zboot.h: No such file or directory 31 | #include | ^~ Link: https://github.com/horms/kexec-tools/actions/runs/5723580523/job/15508425790 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH] kexec: Avoid calculating array size twice
Avoid calculating array size twice in kexec_purgatory_setup_sechdrs().
Once using array_size(), and once open-coded.
Flagged by Coccinelle:
.../kexec_file.c:881:8-25: WARNING: array_size is already used (line 877) to
compute the same size
No functional change intended.
Compile tested only.
Signed-off-by: Simon Horman
---
kernel/kexec_file.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index f989f5f1933b..3f5677679744 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -867,6 +867,7 @@ static int kexec_purgatory_setup_sechdrs(struct
purgatory_info *pi,
{
unsigned long bss_addr;
unsigned long offset;
+ size_t sechdrs_size;
Elf_Shdr *sechdrs;
int i;
@@ -874,11 +875,11 @@ static int kexec_purgatory_setup_sechdrs(struct
purgatory_info *pi,
* The section headers in kexec_purgatory are read-only. In order to
* have them modifiable make a temporary copy.
*/
- sechdrs = vzalloc(array_size(sizeof(Elf_Shdr), pi->ehdr->e_shnum));
+ sechdrs_size = array_size(sizeof(Elf_Shdr), pi->ehdr->e_shnum);
+ sechdrs = vzalloc(sechdrs_size);
if (!sechdrs)
return -ENOMEM;
- memcpy(sechdrs, (void *)pi->ehdr + pi->ehdr->e_shoff,
- pi->ehdr->e_shnum * sizeof(Elf_Shdr));
+ memcpy(sechdrs, (void *)pi->ehdr + pi->ehdr->e_shoff, sechdrs_size);
pi->sechdrs = sechdrs;
offset = 0;
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCHv2 1/6] kexec: Change the image probe's prototype
On Tue, May 16, 2023 at 03:31:19PM +0800, Pingfan Liu wrote:
> As more complicated kernel format occurs such as zboot, where the
> compressed kernel is stored as a payload. The straight forward
> decompression can not meet the demand.
>
> A new image probe method is expected to read in the kernel file and decide
> how to unfold the content by itself.
>
> This patch aims to change the image probe's prototype from
> typedef int (probe_t)(const char *kernel_buf, off_t kernel_size);
> to
> typedef int (probe_t)(const char *kernel_buf, off_t kernel_size,
> struct kexec_info *info);
>
> Later, info can be used to return both the file descriptor and the
> parsed kernel buffer.
>
> In case your are curious, the remaing part of the log describes the
> process of the substitution of the new prototype, which can be divided
> into three groups.
>
> 1. change function pointer and its callsites:
> sed -i 's/(probe_t)(const char \*kernel_buf, off_t
> kernel_size);/(probe_t)(const char \*kernel, off_t kernel_size, struct
> kexec_info \*info);/g' kexec/kexec.h
> sed -i 's/\.probe(\([^,]*\), \([^)]*\))/\.probe(\1, \2, NULL)/g'
> kexec/kexec.c
>
> 2. change the function declaration and definition of each 'probe'
>instance by coccinelle because they may cross lines
>
> The cocci file looks like:
>
> @ rule1 @
> identifier fn =~ "_probe";
> identifier buf, size;
> typedef off_t;
> @@
>
> -int fn(const char *buf, off_t size)
> +int fn(const char *buf, off_t size, struct kexec_info *info)
> {
> ...
> }
>
> @ rule2 @
> identifier fn =~ "_probe";
> identifier buf, size;
> typedef off_t;
> @@
>
> +int fn(const char *buf, off_t size, struct kexec_info *info);
> -int fn(const char *buf, off_t size);
>
> Then running the command
> spatch --sp-file cocci/define.cocci --dir kexec --include-headers >
> ../define.patch
> git apply --directory=kexec ../define.patch
>
> 3. change the direct calls to the probe instances
>
> Originally I planned to achieve this by coccinelle, but failed similar
> to [1]. I have tried using "-I and --include" option for coccinelle, but it
> still did not work.
>
> Checking the direct callsite by "git grep "_probe(" | grep -v const"
> Fortunatelly, it turns out that only a few direct callsites exist, which
> lies in i386, and easy to be amended manually.
>
> Anyway, just FYI, the cocci file looks like:
> @ rule1 @
> identifier fn =~ "_probe";
> identifier buf, size;
> identifier info;
> typedef off_t;
> @@
>
> int fn(const char *buf, off_t size, struct kexec_info *info);
>
> /* change the direct callsite of any probe */
> @ rule2 @
> identifier rule1.fn;
> expression E1, E2;
> @@
>
> fn(E1, E2
> + ,NULL
>)
>
> Then running the command:
> spatch --sp-file cocci/direct.cocci --dir kexec --include-headers
>
> [1]:
> https://lore.kernel.org/all/alpine.DEB.2.22.394.2202280705080.3112@hadrien/T/
>
> Signed-off-by: Pingfan Liu
> To: kexec@lists.infradead.org
> Cc: ho...@verge.net.au
> Cc: a...@kernel.org
> Cc: jeremy.lin...@arm.com
Unfortunately I am seeing a build failure on (at least) sh4 with this change:
../../kexec/arch/sh/kexec-zImage-sh.c:54:5: error: conflicting types for
‘zImage_sh_probe’
54 | int zImage_sh_probe(const char *buf, off_t UNUSED(len))
| ^~~
In file included from ../../kexec/arch/sh/kexec-zImage-sh.c:27:
../../kexec/arch/sh/kexec-sh.h:11:5: note: previous declaration of
‘zImage_sh_probe’ was here
11 | int zImage_sh_probe(const char *buf, off_t len, struct kexec_info
*info);
| ^~~
../../kexec/arch/sh/kexec-zImage-sh.c:29:18: warning: ‘probe_debug’ defined
but not used [-Wunused-const-variable=]
29 | static const int probe_debug = 0;
| ^~~
make[1]: *** [Makefile:124: kexec/arch/sh/kexec-zImage-sh.o] Error 1
make[1]: *** Waiting for unfinished jobs
../../kexec/arch/sh/kexec-netbsd-sh.c:28:18: warning: ‘probe_debug’ defined
but not used [-Wunused-const-variable=]
28 | static const int probe_debug = 0;
| ^~~
Link:
https://github.com/horms/kexec-tools/actions/runs/5068250493/jobs/9100319093#step:5:215
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] parisc: kexec: include reboot.h
On Tue, May 09, 2023 at 05:01:42PM +0800, Baoquan He wrote: > On 05/09/23 at 09:01am, Simon Horman wrote: > > Include reboot.h in machine_kexec.c for declaration of > > machine_crash_shutdown and machine_shutdown. > > > > gcc-12 with W=1 reports: > > > > arch/parisc/kernel/kexec.c:57:6: warning: no previous prototype for > > 'machine_crash_shutdown' [-Wmissing-prototypes] > > 57 | void machine_crash_shutdown(struct pt_regs *regs) > >| ^~ > > arch/parisc/kernel/kexec.c:61:6: warning: no previous prototype for > > 'machine_shutdown' [-Wmissing-prototypes] > > 61 | void machine_shutdown(void) > >| ^~~~ > > > > No functional changes intended. > > Compile tested only. > > > > Signed-off-by: Simon Horman > > Acked-by: Baoquan He > > We may need to find out the places in all architectures and fix all of > them. I did check. It seemed to be needed for riscv, m68k and parisc. I've sent out patches for all three. But I may have missed something. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH] parisc: kexec: include reboot.h
Include reboot.h in machine_kexec.c for declaration of machine_crash_shutdown and machine_shutdown. gcc-12 with W=1 reports: arch/parisc/kernel/kexec.c:57:6: warning: no previous prototype for 'machine_crash_shutdown' [-Wmissing-prototypes] 57 | void machine_crash_shutdown(struct pt_regs *regs) | ^~ arch/parisc/kernel/kexec.c:61:6: warning: no previous prototype for 'machine_shutdown' [-Wmissing-prototypes] 61 | void machine_shutdown(void) | ^~~~ No functional changes intended. Compile tested only. Signed-off-by: Simon Horman --- arch/parisc/kernel/kexec.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/parisc/kernel/kexec.c b/arch/parisc/kernel/kexec.c index 5eb7f30edc1f..db57345a9daf 100644 --- a/arch/parisc/kernel/kexec.c +++ b/arch/parisc/kernel/kexec.c @@ -4,6 +4,8 @@ #include #include #include +#include + #include #include ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v6 07/14] x86: Secure Launch kernel early boot stub
On Fri, May 05, 2023 at 02:58:28PM -0400, Ross Philipson wrote:
> On 5/5/23 13:47, Simon Horman wrote:
> > On Thu, May 04, 2023 at 02:50:16PM +, Ross Philipson wrote:
...
> > > +asmlinkage __visible void sl_check_region(void *base, u32 size)
> > > +{
> > > + sl_check_pmr_coverage(base, size, false);
> > > +}
> >
> > I'm a nit unsure, what to do here, but clang-16 with W=1 says the following.
> >
> > arch/x86/boot/compressed/sl_main.c:533:27: warning: no previous prototype
> > for function 'sl_main' [-Wmissing-prototypes]
> > asmlinkage __visible void sl_main(void *bootparams)
> >^
> > arch/x86/boot/compressed/sl_main.c:533:22: note: declare 'static' if the
> > function is not intended to be used outside of this translation unit
> > asmlinkage __visible void sl_main(void *bootparams)
> > ^
> > static
>
> Yea we will have to look into why this is. This function is only ever called
> from asm code so that might have something to do with this.
Thanks.
...
> > > diff --git a/arch/x86/include/uapi/asm/bootparam.h
> > > b/arch/x86/include/uapi/asm/bootparam.h
> > > index 01d19fc..74e3e7df 100644
> > > --- a/arch/x86/include/uapi/asm/bootparam.h
> > > +++ b/arch/x86/include/uapi/asm/bootparam.h
> > > @@ -26,6 +26,7 @@
> > > /* loadflags */
> > > #define LOADED_HIGH (1<<0)
> > > #define KASLR_FLAG (1<<1)
> > > +#define SLAUNCH_FLAG (1<<2)
> > > #define QUIET_FLAG (1<<5)
> > > #define KEEP_SEGMENTS (1<<6)
> > > #define CAN_USE_HEAP(1<<7)
> >
> > nit: please consider using BIT()
>
> I am a little reluctant to change something like this in an existing header.
> It seems a bit out of scope for the patch set.
Yes, sorry for the noise on this one.
I agree that what you have is the best approach here.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v6 12/14] x86: Secure Launch late initcall platform module
On Thu, May 04, 2023 at 02:50:21PM +, Ross Philipson wrote:
> From: "Daniel P. Smith"
>
> The Secure Launch platform module is a late init module. During the
> init call, the TPM event log is read and measurements taken in the
> early boot stub code are located. These measurements are extended
> into the TPM PCRs using the mainline TPM kernel driver.
>
> The platform module also registers the securityfs nodes to allow
> access to TXT register fields on Intel along with the fetching of
> and writing events to the late launch TPM log.
>
> Signed-off-by: Daniel P. Smith
> Signed-off-by: garnetgrimm
> Signed-off-by: Ross Philipson
Hi Ross,
a few more items from my side.
...
> diff --git a/arch/x86/kernel/slmodule.c b/arch/x86/kernel/slmodule.c
...
> +/*
> + * Securityfs exposure
> + */
> +struct memfile {
> + char *name;
> + void *addr;
> + size_t size;
> +};
> +
> +static struct memfile sl_evtlog = {"eventlog", 0, 0};
I don't think the 0 fields are necessary above, memset will zero
any fields not explicitly set. But if you want to go that way, then
I think the first one should be NULL, as the addr field is a pointer.
> +static void *txt_heap;
> +static struct txt_heap_event_log_pointer2_1_element __iomem *evtlog20;
> +static DEFINE_MUTEX(sl_evt_log_mutex);
> +static ssize_t sl_evtlog_read(struct file *file, char __user *buf,
> + size_t count, loff_t *pos)
> +{
> + ssize_t size;
> +
> + if (!sl_evtlog.addr)
> + return 0;
> +
> + mutex_lock(_evt_log_mutex);
> + size = simple_read_from_buffer(buf, count, pos, sl_evtlog.addr,
> +sl_evtlog.size);
> + mutex_unlock(_evt_log_mutex);
> +
> + return size;
> +}
> +
> +static ssize_t sl_evtlog_write(struct file *file, const char __user *buf,
> + size_t datalen, loff_t *ppos)
nit: the line above doesn't align to the '(' on the line before that.
> +{
> + ssize_t result;
> + char *data;
> +
> + if (!sl_evtlog.addr)
> + return 0;
> +
> + /* No partial writes. */
> + result = -EINVAL;
> + if (*ppos != 0)
> + goto out;
> +
> + data = memdup_user(buf, datalen);
> + if (IS_ERR(data)) {
> + result = PTR_ERR(data);
> + goto out;
> + }
> +
> + mutex_lock(_evt_log_mutex);
> + if (evtlog20)
> + result = tpm20_log_event(evtlog20, sl_evtlog.addr,
> + sl_evtlog.size, datalen, data);
Sparse says that the type of the first argument of tmp20_log_event is:
struct txt_heap_event_log_pointer2_1_element *
However, the type of evtlog20 is:
struct txt_heap_event_log_pointer2_1_element __iomem *
> + else
> + result = tpm12_log_event(sl_evtlog.addr, sl_evtlog.size,
> + datalen, data);
> + mutex_unlock(_evt_log_mutex);
> +
> + kfree(data);
> +out:
> + return result;
> +}
...
> +static long slaunch_expose_securityfs(void)
> +{
> + long ret = 0;
> + int i;
> +
> + slaunch_dir = securityfs_create_dir("slaunch", NULL);
> + if (IS_ERR(slaunch_dir))
> + return PTR_ERR(slaunch_dir);
> +
> + if (slaunch_get_flags() & SL_FLAG_ARCH_TXT) {
> + txt_dir = securityfs_create_dir("txt", slaunch_dir);
> + if (IS_ERR(txt_dir)) {
> + ret = PTR_ERR(txt_dir);
> + goto remove_slaunch;
> + }
> +
> + for (i = 0; i < ARRAY_SIZE(sl_txt_files); i++) {
> + txt_entries[i] = securityfs_create_file(
> + sl_txt_files[i].name, 0440,
> + txt_dir, NULL,
> + sl_txt_files[i].fops);
> + if (IS_ERR(txt_entries[i])) {
> + ret = PTR_ERR(txt_entries[i]);
> + goto remove_files;
> + }
> + }
> +
nit: no blank line here.
> + }
> +
> + if (sl_evtlog.addr > 0) {
addr is a pointer. So perhaps:
if (sl_evtlog.addr) {
> + event_file = securityfs_create_file(
> + sl_evtlog.name, 0440,
> + slaunch_dir, NULL,
> + _evtlog_ops);
> + if (IS_ERR(event_file)) {
> + ret = PTR_ERR(event_file);
> + goto remove_files;
> + }
> + }
> +
> + return 0;
> +
> +remove_files:
> + if (slaunch_get_flags() & SL_FLAG_ARCH_TXT) {
> + while (--i >= 0)
> + securityfs_remove(txt_entries[i]);
> + securityfs_remove(txt_dir);
> + }
> +remove_slaunch:
> + securityfs_remove(slaunch_dir);
> +
> + return ret;
> +}
...
> +static void slaunch_intel_evtlog(void
Re: [PATCH v6 09/14] x86: Secure Launch SMP bringup support
On Thu, May 04, 2023 at 02:50:18PM +, Ross Philipson wrote:
> On Intel, the APs are left in a well documented state after TXT performs
> the late launch. Specifically they cannot have #INIT asserted on them so
> a standard startup via INIT/SIPI/SIPI cannot be performed. Instead the
> early SL stub code parked the APs in a pause/jmp loop waiting for an NMI.
> The modified SMP boot code is called for the Secure Launch case. The
> jump address for the RM piggy entry point is fixed up in the jump where
> the APs are waiting and an NMI IPI is sent to the AP. The AP vectors to
> the Secure Launch entry point in the RM piggy which mimics what the real
> mode code would do then jumps to the standard RM piggy protected mode
> entry point.
>
> Signed-off-by: Ross Philipson
Hi Ross,
just one minor nit on this one.
> /*
> * NOTE - on most systems this is a PHYSICAL apic ID, but on multiquad
> * (ie clustered apic addressing mode), this is a LOGICAL apic ID.
> @@ -1132,6 +1210,13 @@ static int do_boot_cpu(int apicid, int cpu, struct
> task_struct *idle,
> cpumask_clear_cpu(cpu, cpu_initialized_mask);
> smp_mb();
>
> + /* With Intel TXT, the AP startup is totally different */
> + if ((slaunch_get_flags() & (SL_FLAG_ACTIVE|SL_FLAG_ARCH_TXT)) ==
nit: spaces around '|'
> +(SL_FLAG_ACTIVE|SL_FLAG_ARCH_TXT)) {
> + boot_error = slaunch_wakeup_cpu_from_txt(cpu, apicid);
> + goto txt_wake;
> + }
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v6 08/14] x86: Secure Launch kernel late boot stub
On Thu, May 04, 2023 at 02:50:17PM +, Ross Philipson wrote:
> The routine slaunch_setup is called out of the x86 specific setup_arch
> routine during early kernel boot. After determining what platform is
> present, various operations specific to that platform occur. This
> includes finalizing setting for the platform late launch and verifying
> that memory protections are in place.
>
> For TXT, this code also reserves the original compressed kernel setup
> area where the APs were left looping so that this memory cannot be used.
>
> Signed-off-by: Ross Philipson
Hi Ross,
a few nits from my side.
> +/*
> + * The TXT heap is too big to map all at once with early_ioremap
> + * so it is done a table at a time.
> + */
> +static void __init *txt_early_get_heap_table(void __iomem *txt, u32 type,
> + u32 bytes)
> +{
> + u64 base, size, offset = 0;
> + void *heap;
> + int i;
> +
> + if (type > TXT_SINIT_TABLE_MAX)
> + slaunch_txt_reset(txt,
> + "Error invalid table type for early heap walk\n",
> + SL_ERROR_HEAP_WALK);
nit: the indentation should align to the opening '('.
slaunch_txt_reset(txt,
"Error invalid table type for early heap
walk\n",
SL_ERROR_HEAP_WALK);
Likewise in a few other places in this patch.
...
> +static void __init slaunch_txt_reserve_range(u64 base, u64 size)
> +{
> + int type;
> +
> + type = e820__get_entry_type(base, base + size - 1);
> + if (type == E820_TYPE_RAM) {
> + pr_info("memblock reserve base: %llx size: %llx\n", base, size);
> + memblock_reserve(base, size);
> + }
> +}
> +
> +/*
> + * For Intel, certain regions of memory must be marked as reserved by putting
> + * them on the memblock reserved list if they are not already e820 reserved.
> + * This includes:
> + * - The TXT HEAP
> + * - The ACM area
> + * - The TXT private register bank
> + * - The MDR list sent to the MLE by the ACM (see TXT specification)
> + * (Normally the above are properly reserved by firmware but if it was not
> + * done, reserve them now)
> + * - The AP wake block
> + * - TPM log external to the TXT heap
> + *
> + * Also if the low PMR doesn't cover all memory < 4G, any RAM regions above
> + * the low PMR must be reservered too.
nit: s/reservered/reserved/
> + */
> +static void __init slaunch_txt_reserve(void __iomem *txt)
> +{
> + struct txt_sinit_memory_descriptor_record *mdr;
> + struct txt_sinit_mle_data *sinit_mle_data;
> + u64 base, size, heap_base, heap_size;
> + u32 mdrnum, mdroffset, mdrslen;
> + u32 field_offset, i;
> + void *mdrs;
> +
> + base = TXT_PRIV_CONFIG_REGS_BASE;
> + size = TXT_PUB_CONFIG_REGS_BASE - TXT_PRIV_CONFIG_REGS_BASE;
> + slaunch_txt_reserve_range(base, size);
> +
> + memcpy_fromio(_base, txt + TXT_CR_HEAP_BASE, sizeof(heap_base));
> + memcpy_fromio(_size, txt + TXT_CR_HEAP_SIZE, sizeof(heap_size));
> + slaunch_txt_reserve_range(heap_base, heap_size);
> +
> + memcpy_fromio(, txt + TXT_CR_SINIT_BASE, sizeof(base));
> + memcpy_fromio(, txt + TXT_CR_SINIT_SIZE, sizeof(size));
> + slaunch_txt_reserve_range(base, size);
> +
> + field_offset = offsetof(struct txt_sinit_mle_data,
> + sinit_vtd_dmar_table_size);
> + sinit_mle_data = txt_early_get_heap_table(txt, TXT_SINIT_MLE_DATA_TABLE,
> + field_offset);
> +
> + mdrnum = sinit_mle_data->num_of_sinit_mdrs;
> + mdroffset = sinit_mle_data->sinit_mdrs_table_offset;
> +
> + txt_early_put_heap_table(sinit_mle_data, field_offset);
> +
> + if (!mdrnum)
> + goto nomdr;
> +
> + mdrslen = mdrnum * sizeof(struct txt_sinit_memory_descriptor_record);
> +
> + mdrs = txt_early_get_heap_table(txt, TXT_SINIT_MLE_DATA_TABLE,
> + mdroffset + mdrslen - 8);
> +
> + mdr = mdrs + mdroffset - 8;
> +
> + for (i = 0; i < mdrnum; i++, mdr++) {
> + /* Spec says some entries can have length 0, ignore them */
> + if (mdr->type > 0 && mdr->length > 0)
> + slaunch_txt_reserve_range(mdr->address, mdr->length);
> + }
> +
> + txt_early_put_heap_table(mdrs, mdroffset + mdrslen - 8);
> +
> +nomdr:
> + slaunch_txt_reserve_range(ap_wake_info.ap_wake_block,
> + ap_wake_info.ap_wake_block_size);
> +
> + /*
> + * Earlier checks ensured that the event log was properly situated
> + * either inside the TXT heap or outside. This is a check to see if the
> + * event log needs to be reserved. If it is in the TXT heap, it is
> + * already reserved.
> + */
> + if (evtlog_addr < heap_base || evtlog_addr > (heap_base + heap_size))
> + slaunch_txt_reserve_range(evtlog_addr, evtlog_size);
>
Re: [PATCH v6 07/14] x86: Secure Launch kernel early boot stub
On Thu, May 04, 2023 at 02:50:16PM +, Ross Philipson wrote:
> The Secure Launch (SL) stub provides the entry point for Intel TXT (and
> later AMD SKINIT) to vector to during the late launch. The symbol
> sl_stub_entry is that entry point and its offset into the kernel is
> conveyed to the launching code using the MLE (Measured Launch
> Environment) header in the structure named mle_header. The offset of the
> MLE header is set in the kernel_info. The routine sl_stub contains the
> very early late launch setup code responsible for setting up the basic
> environment to allow the normal kernel startup_32 code to proceed. It is
> also responsible for properly waking and handling the APs on Intel
> platforms. The routine sl_main which runs after entering 64b mode is
> responsible for measuring configuration and module information before
> it is used like the boot params, the kernel command line, the TXT heap,
> an external initramfs, etc.
>
> Signed-off-by: Ross Philipson
...
> diff --git a/arch/x86/boot/compressed/sl_main.c
> b/arch/x86/boot/compressed/sl_main.c
...
> +static void *evtlog_base;
> +static u32 evtlog_size;
> +static struct txt_heap_event_log_pointer2_1_element *log20_elem;
> +static u32 tpm_log_ver = SL_TPM12_LOG;
> +struct tcg_efi_specid_event_algs tpm_algs[SL_TPM20_MAX_ALGS] = {0};
tpm_algs seems to only be used in this file.
Should it be static?
> +
> +extern u32 sl_cpu_type;
> +extern u32 sl_mle_start;
> +extern struct boot_params *boot_params;
> +
> +static u64 sl_txt_read(u32 reg)
Perhaps reg should have an __iomem annotation.
> +{
> + return readq((void *)(u64)(TXT_PRIV_CONFIG_REGS_BASE + reg));
> +}
> +
> +static void sl_txt_write(u32 reg, u64 val)
Likewise here.
...
> +static void sl_check_pmr_coverage(void *base, u32 size, bool allow_hi)
> +{
> + struct txt_os_sinit_data *os_sinit_data;
> + void *end = base + size;
> + void *txt_heap;
> +
> + if (!(sl_cpu_type & SL_CPU_INTEL))
> + return;
> +
> + txt_heap = (void *)sl_txt_read(TXT_CR_HEAP_BASE);
> + os_sinit_data = txt_os_sinit_data_start(txt_heap);
> +
> + if ((end >= (void *)0x1ULL) &&
> + (base < (void *)0x1ULL))
> + sl_txt_reset(SL_ERROR_REGION_STRADDLE_4GB);
> +
> + /*
> + * Note that the late stub code validates that the hi PMR covers
> + * all memory above 4G. At this point the code can only check that
> + * regions are within the hi PMR but that is sufficient.
> + */
> + if ((end > (void *)0x1ULL) &&
> + (base >= (void *)0x1ULL)) {
> + if (allow_hi) {
> + if (end >= (void *)(os_sinit_data->vtd_pmr_hi_base +
> +os_sinit_data->vtd_pmr_hi_size))
> + sl_txt_reset(SL_ERROR_BUFFER_BEYOND_PMR);
> + } else
> + sl_txt_reset(SL_ERROR_REGION_ABOVE_4GB);
nit: if any arm of a condition has '{}' then all arms should have them.
So:
} else {
sl_txt_reset(SL_ERROR_REGION_ABOVE_4GB);
}
Also elsewhere in this patch.
> + }
> +
> + if (end >= (void *)os_sinit_data->vtd_pmr_lo_size)
> + sl_txt_reset(SL_ERROR_BUFFER_BEYOND_PMR);
> +}
> +
> +/*
> + * Some MSRs are modified by the pre-launch code including the MTRRs.
> + * The early MLE code has to restore these values. This code validates
> + * the values after they are measured.
> + */
> +static void sl_txt_validate_msrs(struct txt_os_mle_data *os_mle_data)
> +{
> + struct slr_txt_mtrr_state *saved_bsp_mtrrs;
> + u64 mtrr_caps, mtrr_def_type, mtrr_var;
> + struct slr_entry_intel_info *txt_info;
> + u64 misc_en_msr;
> + u32 vcnt, i;
> +
> + txt_info = (struct slr_entry_intel_info *)os_mle_data->txt_info;
> + saved_bsp_mtrrs = &(txt_info->saved_bsp_mtrrs);
nit: unnecessary parentheses
...
> +static void sl_validate_event_log_buffer(void)
> +{
> + struct txt_os_sinit_data *os_sinit_data;
> + void *txt_heap, *txt_end;
> + void *mle_base, *mle_end;
> + void *evtlog_end;
> +
> + if ((u64)evtlog_size > (LLONG_MAX - (u64)evtlog_base))
> + sl_txt_reset(SL_ERROR_INTEGER_OVERFLOW);
> + evtlog_end = evtlog_base + evtlog_size;
> +
> + txt_heap = (void *)sl_txt_read(TXT_CR_HEAP_BASE);
> + txt_end = txt_heap + sl_txt_read(TXT_CR_HEAP_SIZE);
> + os_sinit_data = txt_os_sinit_data_start(txt_heap);
> +
> + mle_base = (void *)(u64)sl_mle_start;
> + mle_end = mle_base + os_sinit_data->mle_size;
> +
> + /*
> + * This check is to ensure the event log buffer does not overlap with
> + * the MLE image.
> + */
> + if ((evtlog_base >= mle_end) &&
> + (evtlog_end > mle_end))
> + goto pmr_check; /* above */
Ditto.
Also, the if condition could be one line.
Also in several other places in this patch.
> +
> + if ((evtlog_end <= mle_base)
Re: [PATCH v6 06/14] x86: Add early SHA support for Secure Launch early measurements
On Thu, May 04, 2023 at 02:50:15PM +, Ross Philipson wrote:
> From: "Daniel P. Smith"
>
> The SHA algorithms are necessary to measure configuration information into
> the TPM as early as possible before using the values. This implementation
> uses the established approach of #including the SHA libraries directly in
> the code since the compressed kernel is not uncompressed at this point.
>
> The SHA code here has its origins in the code from the main kernel:
>
> commit c4d5b9ffa31f ("crypto: sha1 - implement base layer for SHA-1")
>
> That code could not be pulled directly into the setup portion of the
> compressed kernel because of other dependencies it pulls in. The result
> is this is a modified copy of that code that still leverages the core
> SHA algorithms.
>
> Signed-off-by: Daniel P. Smith
> Signed-off-by: Ross Philipson
> ---
> arch/x86/boot/compressed/Makefile | 2 +
> arch/x86/boot/compressed/early_sha1.c | 97
> +
> arch/x86/boot/compressed/early_sha1.h | 17 ++
> arch/x86/boot/compressed/early_sha256.c | 7 +++
> lib/crypto/sha1.c | 4 ++
> lib/crypto/sha256.c | 8 +++
> 6 files changed, 135 insertions(+)
> create mode 100644 arch/x86/boot/compressed/early_sha1.c
> create mode 100644 arch/x86/boot/compressed/early_sha1.h
> create mode 100644 arch/x86/boot/compressed/early_sha256.c
>
> diff --git a/arch/x86/boot/compressed/Makefile
> b/arch/x86/boot/compressed/Makefile
> index 6b6cfe6..1d327d4 100644
> --- a/arch/x86/boot/compressed/Makefile
> +++ b/arch/x86/boot/compressed/Makefile
> @@ -112,6 +112,8 @@ vmlinux-objs-$(CONFIG_EFI) += $(obj)/efi.o
> vmlinux-objs-$(CONFIG_EFI_MIXED) += $(obj)/efi_mixed.o
> vmlinux-objs-$(CONFIG_EFI_STUB) +=
> $(objtree)/drivers/firmware/efi/libstub/lib.a
>
> +vmlinux-objs-$(CONFIG_SECURE_LAUNCH) += $(obj)/early_sha1.o
> $(obj)/early_sha256.o
> +
> $(obj)/vmlinux: $(vmlinux-objs-y) FORCE
> $(call if_changed,ld)
>
> diff --git a/arch/x86/boot/compressed/early_sha1.c
> b/arch/x86/boot/compressed/early_sha1.c
> new file mode 100644
> index 000..524ec23
> --- /dev/null
> +++ b/arch/x86/boot/compressed/early_sha1.c
> @@ -0,0 +1,97 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2022 Apertus Solutions, LLC.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "early_sha1.h"
> +
> +#define SHA1_DISABLE_EXPORT
Hi Ross,
I could be mistaken, but it seems to me that *_DISABLE_EXPORT
is a mechanism of this patch to disable exporting symbols
(use of EXPORT_SYMBOL), at compile time.
If so, this doesn't strike me as something that should be part of upstream
kernel code. Could you consider dropping this part of the patch?
...
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v6 05/14] x86: Secure Launch main header file
On Thu, May 04, 2023 at 02:50:14PM +, Ross Philipson wrote:
> Introduce the main Secure Launch header file used in the early SL stub
> and the early setup code.
>
> Signed-off-by: Ross Philipson
> ---
> include/linux/slaunch.h | 513
>
> 1 file changed, 513 insertions(+)
> create mode 100644 include/linux/slaunch.h
>
> diff --git a/include/linux/slaunch.h b/include/linux/slaunch.h
...
> +/* TXTCR_STS status bits */
> +#define TXT_SENTER_DONE_STS (1<<0)
> +#define TXT_SEXIT_DONE_STS (1<<1)
nit: Please consider using BIT()
...
> +/*
> + * External functions avalailable in mainline kernel.
> + */
> +extern void slaunch_setup_txt(void);
> +extern u32 slaunch_get_flags(void);
> +extern struct sl_ap_wake_info *slaunch_get_ap_wake_info(void);
> +extern struct acpi_table_header *slaunch_get_dmar_table(struct
> acpi_table_header *dmar);
> +extern void __noreturn slaunch_txt_reset(void __iomem *txt,
> + const char *msg, u64 error);
> +extern void slaunch_finalize(int do_sexit);
I think that extern should be avoided.
Perhaps these are in a header file that can be included?
> +
> +#endif /* !__ASSEMBLY */
> +
> +#else
> +
> +#define slaunch_setup_txt() do { } while (0)
> +#define slaunch_get_flags() 0
> +#define slaunch_get_dmar_table(d)(d)
> +#define slaunch_finalize(d) do { } while (0)
I think it is usual to use static functions for this purpose.
Usually they end up in header files as static inline functions.
> +
> +#endif /* !IS_ENABLED(CONFIG_SECURE_LAUNCH) */
> +
> +#endif /* _LINUX_SLAUNCH_H */
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v6 04/14] x86: Secure Launch Resource Table header file
On Thu, May 04, 2023 at 02:50:13PM +, Ross Philipson wrote:
> Introduce the Secure Launch Resource Table which forms the formal
> interface between the pre and post launch code.
>
> Signed-off-by: Ross Philipson
> ---
> include/linux/slr_table.h | 270
> ++
> 1 file changed, 270 insertions(+)
> create mode 100644 include/linux/slr_table.h
>
> diff --git a/include/linux/slr_table.h b/include/linux/slr_table.h
...
> +static inline void *slr_end_of_entrys(struct slr_table *table)
> +{
> + return (((void *)table) + table->size);
> +}
> +
> +static inline struct slr_entry_hdr *
> +slr_next_entry(struct slr_table *table,
> + struct slr_entry_hdr *curr)
nit: The indentation of the line above doesn't align with the '(' on
the line before it.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v6 02/14] Documentation/x86: Secure Launch kernel documentation
On Thu, May 04, 2023 at 02:50:11PM +, Ross Philipson wrote: > Introduce background, overview and configuration/ABI information > for the Secure Launch kernel feature. > > Signed-off-by: Daniel P. Smith > Signed-off-by: Ross Philipson Hi Ross and Daniel, some minor nits from my side. > --- > Documentation/security/index.rst | 1 + > Documentation/security/launch-integrity/index.rst | 10 + > .../security/launch-integrity/principles.rst | 313 > .../launch-integrity/secure_launch_details.rst | 564 > + > .../launch-integrity/secure_launch_overview.rst| 220 > 5 files changed, 1108 insertions(+) > create mode 100644 Documentation/security/launch-integrity/index.rst > create mode 100644 Documentation/security/launch-integrity/principles.rst > create mode 100644 > Documentation/security/launch-integrity/secure_launch_details.rst > create mode 100644 > Documentation/security/launch-integrity/secure_launch_overview.rst > > diff --git a/Documentation/security/index.rst > b/Documentation/security/index.rst > index 6ed8d2f..fade37e 100644 > --- a/Documentation/security/index.rst > +++ b/Documentation/security/index.rst > @@ -18,3 +18,4 @@ Security Documentation > digsig > landlock > secrets/index > + launch-integrity/index > diff --git a/Documentation/security/launch-integrity/index.rst > b/Documentation/security/launch-integrity/index.rst > new file mode 100644 > index 000..28eed91d > --- /dev/null > +++ b/Documentation/security/launch-integrity/index.rst > @@ -0,0 +1,10 @@ I believe an SPDX tag should go at the top of each .rst file. > += > +System Launch Integrity documentation > += > + > +.. toctree:: > + > + principles > + secure_launch_overview > + secure_launch_details > + > diff --git a/Documentation/security/launch-integrity/principles.rst > b/Documentation/security/launch-integrity/principles.rst > new file mode 100644 > index 000..73cf063 > --- /dev/null > +++ b/Documentation/security/launch-integrity/principles.rst > @@ -0,0 +1,313 @@ > +=== > +System Launch Integrity > +=== > + > +This document serves to establish a common understanding of what is system > +launch, the integrity concern for system launch, and why using a Root of > Trust > +(RoT) from a Dynamic Launch may be desired. Through out this document > +terminology from the Trusted Computing Group (TCG) and National Institue for s/Institue/Institute/ ... > +Trust Chains > + > + > +Bulding upon the understanding of security mechanisms to establish load-time s/Bulding/Building/ ... > diff --git > a/Documentation/security/launch-integrity/secure_launch_details.rst > b/Documentation/security/launch-integrity/secure_launch_details.rst ... > +Secure Launch Resource Table > + > + > +The Secure Launch Resource Table (SLRT) is a platform-agnostic, standard > format > +for providing information for the pre-launch environment and to pass > +information to the post-launch environment. The table is populated by one or > +more bootloaders in the boot chain and used by Secure Launch on how to setup > +the environment during post-launch. The details for the SLRT are documented > +in the TrenchBoot Secure Launch Specifcation [3]_. s/Specifcation/Specification/ ... ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 3/5] arm64: change the prototype of image probe function
On Fri, May 05, 2023 at 10:54:35AM +0800, Pingfan Liu wrote: > Changing the aarch64 probe's prototype from > typedef int (probe_t)(const char *kernel_buf, off_t kernel_size); > to > typedef int (probe_t)(const char *kernel_buf, off_t kernel_size, struct > kexec_info *info); > > Later, info can be used to return both the file descriptor and parsed kernel > buffer. The fd is passed to sys_kexec_file_load, and the parsed kernel > buffer is used by image's load function. > > Signed-off-by: Pingfan Liu Hi Pingfan, I am seeing a build failure on ARM (32bit). 138 | int zImage_arm_probe(const char *UNUSED(buf), off_t UNUSED(len)) | ^~~~ In file included from ../../kexec/arch/arm/kexec-zImage-arm.c:21: ../../kexec/arch/arm/kexec-arm.h:12:5: note: previous declaration of ‘zImage_arm_probe’ was here 12 | int zImage_arm_probe(const char *buf, off_t len, struct kexec_info *info); | ^~~~ make[1]: *** [Makefile:124: kexec/arch/arm/kexec-zImage-arm.o] Error 1 make[1]: *** Waiting for unfinished jobs make[1]: Leaving directory '/home/runner/work/kexec-tools/kexec-tools/kexec-tools-2.0.26.git/_build/sub' make: *** [Makefile:276: distcheck] Error 2 Error: Process completed with exit code 2. Link: https://github.com/horms/kexec-tools/actions/runs/4895124719/jobs/8740272103 ... > diff --git a/kexec/kexec.h b/kexec/kexec.h > index 0d820ad..6e8430e 100644 > --- a/kexec/kexec.h > +++ b/kexec/kexec.h > @@ -191,7 +191,13 @@ unsigned long locate_hole(struct kexec_info *info, > unsigned long hole_min, unsigned long hole_max, > int hole_end); > > +#ifndef __aarch64__ > typedef int (probe_t)(const char *kernel_buf, off_t kernel_size); > +#else > +typedef int (probe_t)(const char *kern_fname, off_t kernel_size, > + struct kexec_info *info); > +#endif > + This seems kind of unfortunate. Could we update the prototype for all architectures? ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 1/5] kexec: Adding missing free for kernel_buf
On Fri, May 05, 2023 at 10:54:33AM +0800, Pingfan Liu wrote: > slurp_decompress_file() allocates memory but nowhere to free it. > Adding that missing free. Hi Pingfan, There seem to be: a) other places where slurp_decompress_file() is called and; b) other places where do_kexec_file_load() returns. I wonder if a more comprehensive fix appropriate. > > Signed-off-by: Pingfan Liu > To: kexec@lists.infradead.org > Cc: ho...@verge.net.au > Cc: a...@kernel.org > Cc: jeremy.lin...@arm.com > --- > kexec/kexec.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/kexec/kexec.c b/kexec/kexec.c > index 36bb2ad..614cd1d 100644 > --- a/kexec/kexec.c > +++ b/kexec/kexec.c > @@ -1379,6 +1379,7 @@ static int do_kexec_file_load(int fileind, int argc, > char **argv, > } > } > > + free(kernel_buf); > close(kernel_fd); > return ret; > } > -- > 2.31.1 > ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH] m68k: kexec: include reboot.h
Include reboot.h in machine_kexec.c for declaration of machine_crash_shutdown and machine_shutdown. gcc-12 with W=1 reports: arch/m68k/kernel/machine_kexec.c:26:6: warning: no previous prototype for 'machine_shutdown' [-Wmissing-prototypes] 26 | void machine_shutdown(void) | ^~~~ arch/m68k/kernel/machine_kexec.c:30:6: warning: no previous prototype for 'machine_crash_shutdown' [-Wmissing-prototypes] 30 | void machine_crash_shutdown(struct pt_regs *regs) | ^~ No functional changes intended. Compile tested only. Signed-off-by: Simon Horman --- arch/m68k/kernel/machine_kexec.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/m68k/kernel/machine_kexec.c b/arch/m68k/kernel/machine_kexec.c index 206f84983120..739875540e89 100644 --- a/arch/m68k/kernel/machine_kexec.c +++ b/arch/m68k/kernel/machine_kexec.c @@ -6,6 +6,7 @@ #include #include #include +#include #include #include ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v9 4/4] tpm/kexec: Duplicate TPM measurement log in of-tree for kexec
On Tue, Apr 18, 2023 at 09:44:09AM -0400, Stefan Berger wrote:
> The memory area of the TPM measurement log is currently not properly
> duplicated for carrying it across kexec when an Open Firmware
> Devicetree is used. Therefore, the contents of the log get corrupted.
> Fix this for the kexec_file_load() syscall by allocating a buffer and
> copying the contents of the existing log into it. The new buffer is
> preserved across the kexec and a pointer to it is available when the new
> kernel is started. To achieve this, store the allocated buffer's address
> in the flattened device tree (fdt) under the name linux,tpm-kexec-buffer
> and search for this entry early in the kernel startup before the TPM
> subsystem starts up. Adjust the pointer in the of-tree stored under
> linux,sml-base to point to this buffer holding the preserved log. The TPM
> driver can then read the base address from this entry when making the log
> available. Invalidate the log by removing 'linux,sml-base' from the
> devicetree if anything goes wrong with updating the buffer.
>
> Use subsys_initcall() to call the function to restore the buffer even if
> the TPM subsystem or driver are not used. This allows the buffer to be
> carried across the next kexec without involvement of the TPM subsystem
> and ensures a valid buffer pointed to by the of-tree.
Hi Stefan,
some minor feedback from my side.
> Use the subsys_initcall(), rather than an ealier initcall, since
nit via checkpatch.pl --codespell: s/ealier/earlier/
> page_is_ram() in get_kexec_buffer() only starts working at this stage.
>
> Signed-off-by: Stefan Berger
> Cc: Rob Herring
> Cc: Frank Rowand
> Cc: Eric Biederman
> Tested-by: Nageswara R Sastry
> Tested-by: Coiby Xu
> Reviewed-by: Rob Herring
...
> +void tpm_add_kexec_buffer(struct kimage *image)
> +{
> + struct kexec_buf kbuf = { .image = image, .buf_align = 1,
> + .buf_min = 0, .buf_max = ULONG_MAX,
> + .top_down = true };
> + struct device_node *np;
> + void *buffer;
> + u32 size;
> + u64 base;
> + int ret;
> +
> + if (!IS_ENABLED(CONFIG_PPC64))
> + return;
> +
> + np = of_find_node_by_name(NULL, "vtpm");
> + if (!np)
> + return;
> +
> + if (of_tpm_get_sml_parameters(np, , ) < 0)
> + return;
> +
> + buffer = vmalloc(size);
> + if (!buffer)
> + return;
> + memcpy(buffer, __va(base), size);
> +
> + kbuf.buffer = buffer;
> + kbuf.bufsz = size;
> + kbuf.memsz = size;
> + ret = kexec_add_buffer();
> + if (ret) {
> + pr_err("Error passing over kexec TPM measurement log buffer:
> %d\n",
> +ret);
Does buffer need to be freed here?
> + return;
> + }
> +
> + image->tpm_buffer = buffer;
> + image->tpm_buffer_addr = kbuf.mem;
> + image->tpm_buffer_size = size;
> +}
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH] arm64: kexec: include reboot.h
Include reboot.h in machine_kexec.c for declaration of machine_crash_shutdown. gcc-12 with W=1 reports: arch/arm64/kernel/machine_kexec.c:257:6: warning: no previous prototype for 'machine_crash_shutdown' [-Wmissing-prototypes] 257 | void machine_crash_shutdown(struct pt_regs *regs) No functional changes intended. Compile tested only. Signed-off-by: Simon Horman --- arch/arm64/kernel/machine_kexec.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c index 54f8e2d081c4..078910db77a4 100644 --- a/arch/arm64/kernel/machine_kexec.c +++ b/arch/arm64/kernel/machine_kexec.c @@ -11,6 +11,7 @@ #include #include #include +#include #include #include ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH -next v4 1/2] riscv: kdump: Implement crashkernel=X,[high,low]
On Mon, Apr 10, 2023 at 09:05:52PM +0800, Chen Jiahao wrote: > On riscv, the current crash kernel allocation logic is trying to > allocate within 32bit addressible memory region by default, if > failed, try to allocate without 4G restriction. > > In need of saving DMA zone memory while allocating a relatively large > crash kernel region, allocating the reserved memory top down in > high memory, without overlapping the DMA zone, is a mature solution. > Here introduce the parameter option crashkernel=X,[high,low]. > > One can reserve the crash kernel from high memory above DMA zone range > by explicitly passing "crashkernel=X,high"; or reserve a memory range > below 4G with "crashkernel=X,low". > > Signed-off-by: Chen Jiahao > Acked-by: Guo Ren > Reviewed-by: Zhen Lei Reviewed-by: Simon Horman ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH -next v3 0/2] support allocating crashkernel above 4G explicitly on riscv
On Fri, Apr 07, 2023 at 06:02:04AM +0800, Chen Jiahao wrote: > On riscv, the current crash kernel allocation logic is trying to > allocate within 32bit addressible memory region by default, if > failed, try to allocate without 4G restriction. > > In need of saving DMA zone memory while allocating a relatively large > crash kernel region, allocating the reserved memory top down in > high memory, without overlapping the DMA zone, is a mature solution. > Hence this patchset introduces the parameter option crashkernel=X,[high,low]. > > One can reserve the crash kernel from high memory above DMA zone range > by explicitly passing "crashkernel=X,high"; or reserve a memory range > below 4G with "crashkernel=X,low". Besides, there are few rules need > to take notice: > 1. "crashkernel=X,[high,low]" will be ignored if "crashkernel=size" >is specified. > 2. "crashkernel=X,low" is valid only when "crashkernel=X,high" is passed >and there is enough memory to be allocated under 4G. > 3. When allocating crashkernel above 4G and no "crashkernel=X,low" is >specified, a 128M low memory will be allocated automatically for >swiotlb bounce buffer. > See Documentation/admin-guide/kernel-parameters.txt for more information. > > To verify loading the crashkernel, adapted kexec-tools is attached below: > https://github.com/chenjh005/kexec-tools/tree/build-test-riscv-v2 Are you planning to submit the kexec-tools patches too? ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH -next v3 2/2] docs: kdump: Update the crashkernel description for riscv
On Fri, Apr 07, 2023 at 06:02:06AM +0800, Chen Jiahao wrote: > Now "crashkernel=" parameter on riscv has been updated to support > crashkernel=X,[high,low]. Through which we can reserve memory region > above/within 32bit addressible DMA zone. > > Here update the parameter description accordingly. > > Signed-off-by: Chen Jiahao Reviewed-by: Simon Horman ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH -next v3 1/2] riscv: kdump: Implement crashkernel=X,[high,low]
On Fri, Apr 07, 2023 at 06:02:05AM +0800, Chen Jiahao wrote:
> On riscv, the current crash kernel allocation logic is trying to
> allocate within 32bit addressible memory region by default, if
> failed, try to allocate without 4G restriction.
>
> In need of saving DMA zone memory while allocating a relatively large
> crash kernel region, allocating the reserved memory top down in
> high memory, without overlapping the DMA zone, is a mature solution.
> Here introduce the parameter option crashkernel=X,[high,low].
>
> One can reserve the crash kernel from high memory above DMA zone range
> by explicitly passing "crashkernel=X,high"; or reserve a memory range
> below 4G with "crashkernel=X,low".
>
> Signed-off-by: Chen Jiahao
...
> @@ -1180,14 +1206,37 @@ static void __init reserve_crashkernel(void)
> return;
> }
>
> - ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
> + ret = parse_crashkernel(cmdline, memblock_phys_mem_size(),
> _size, _base);
> - if (ret || !crash_size)
> + if (ret == -ENOENT) {
> + /*
> + * crashkernel=X,[high,low] can be specified or not, but
> + * invalid value is not allowed.
nit: Perhaps something like this would be easier to correlate with the
code that follows:
/* Fallback to crashkernel=X,[high,low] */
> + */
> + ret = parse_crashkernel_high(cmdline, 0, _size,
> _base);
> + if (ret || !crash_size)
> + return;
> +
> + /*
> + * crashkernel=Y,low is valid only when crashkernel=X,high
> + * is passed and high memory is reserved successful.
nit: s/successful/successfully/
> + */
> + ret = parse_crashkernel_low(cmdline, 0, _low_size,
> _base);
> + if (ret == -ENOENT)
> + crash_low_size = DEFAULT_CRASH_KERNEL_LOW_SIZE;
> + else if (ret)
> + return;
> +
> + search_start = search_low_max;
> + } else if (ret || !crash_size) {
> + /* Invalid argument value specified */
> return;
> + }
...
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH -next v3 1/2] riscv: kdump: Implement crashkernel=X,[high,low]
On Fri, Apr 07, 2023 at 05:06:24PM +0800, Guo Ren wrote: > On Thu, Apr 6, 2023 at 10:06 PM Chen Jiahao wrote: > > > > On riscv, the current crash kernel allocation logic is trying to > > allocate within 32bit addressible memory region by default, if > > failed, try to allocate without 4G restriction. > > > > In need of saving DMA zone memory while allocating a relatively large > > crash kernel region, allocating the reserved memory top down in > > high memory, without overlapping the DMA zone, is a mature solution. > > Here introduce the parameter option crashkernel=X,[high,low]. > > > > One can reserve the crash kernel from high memory above DMA zone range > > by explicitly passing "crashkernel=X,high"; or reserve a memory range > > below 4G with "crashkernel=X,low". > Asked-by: Guo Ren Perhaps 'Acked-by' :) ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v4 1/2] kexec: Support purgatories with .text.hot sections
On Mon, Mar 27, 2023 at 05:06:53PM +0200, Ricardo Ribalda wrote:
> Clang16 links the purgatory text in two sections:
>
> [ 1] .text PROGBITS 0040
>11a1 AX 0 0 16
> [ 2] .rela.textRELA 3498
>0648 0018 I 24 1 8
> ...
> [17] .text.hot.PROGBITS 3220
>020b AX 0 0 1
> [18] .rela.text.hot. RELA 4428
>0078 0018 I 2417 8
>
> And both of them have their range [sh_addr ... sh_addr+sh_size] on the
> area pointed by `e_entry`.
>
> This causes that image->start is calculated twice, once for .text and
> another time for .text.hot. The second calculation leaves image->start
> in a random location.
>
> Because of this, the system crashes inmediatly after:
s/inmediatly/immediately/
>
> kexec_core: Starting new kernel
>
> Cc: sta...@vger.kernel.org
Maybe a fixes tag is warranted here.
> Reviewed-by: Ross Zwisler
> Signed-off-by: Ricardo Ribalda
> ---
> kernel/kexec_file.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index f1a0e4e3fb5c..25a37d8f113a 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -901,10 +901,21 @@ static int kexec_purgatory_setup_sechdrs(struct
> purgatory_info *pi,
> }
>
> offset = ALIGN(offset, align);
> +
> + /*
> + * Check if the segment contains the entry point, if so,
> + * calculate the value of image->start based on it.
> + * If the compiler has produced more than one .text sections
nit: s/sections/section/
> + * (Eg: .text.hot), they are generally after the main .text
If this is the general case, then are there cases where this doesn't hold?
> + * section, and they shall not be used to calculate
> + * image->start. So do not re-calculate image->start if it
> + * is not set to the initial value.
> + */
> if (sechdrs[i].sh_flags & SHF_EXECINSTR &&
> pi->ehdr->e_entry >= sechdrs[i].sh_addr &&
> pi->ehdr->e_entry < (sechdrs[i].sh_addr
> - + sechdrs[i].sh_size)) {
> + + sechdrs[i].sh_size) &&
> + kbuf->image->start == pi->ehdr->e_entry) {
> kbuf->image->start -= sechdrs[i].sh_addr;
> kbuf->image->start += kbuf->mem + offset;
> }
>
> --
> 2.40.0.348.gf938b09366-goog-b4-0.11.0-dev-696ae
>
> ___
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH -next 1/2] riscv: kdump: Implement crashkernel=X,[high,low]
On Tue, Mar 21, 2023 at 04:42:43AM +0800, Chen Jiahao wrote:
> On riscv, the current crash kernel allocation logic is trying to
> allocate within 32bit addressible memory region by default, if
> failed, try to allocate without 4G restriction.
>
> In need of saving DMA zone memory while allocating a relatively large
> crash kernel region, allocating the reserved memory top down in
> high memory, without overlapping the DMA zone, is a mature solution.
> Here introduce the parameter option crashkernel=X,[high,low].
>
> We can reserve the crash kernel from high memory above DMA zone range
> by explicitly passing "crashkernel=X,high"; or reserve a memory range
> below 4G with "crashkernel=X,low".
>
> Signed-off-by: Chen Jiahao
Some minor nits, but I don't think there is any need to respin for them.
Reviewed-by: Simon Horman
...
> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> index 478d6763a01a..5def2174b243 100644
> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
...
> @@ -1201,16 +1242,25 @@ static void __init reserve_crashkernel(void)
>*/
> crash_base = memblock_phys_alloc_range(crash_size, PMD_SIZE,
> search_start,
> -min(search_end, (unsigned long)
> SZ_4G));
> +min(search_end, (unsigned long)
> dma32_phys_limit));
nit: While here, you could drop the space before 'ma32_phys_limit'.
Or perhaps use min_t, which seems appropriate here.
> if (crash_base == 0) {
> /* Try again without restricting region to 32bit addressible
> memory */
> crash_base = memblock_phys_alloc_range(crash_size, PMD_SIZE,
> - search_start, search_end);
> +search_start,
> search_end);
> if (crash_base == 0) {
> pr_warn("crashkernel: couldn't allocate %lldKB\n",
> crash_size >> 10);
> return;
> }
> +
> + if (!crash_low_size)
> + crash_low_size = DEFAULT_CRASH_KERNEL_LOW_SIZE;
> + }
> +
> + if ((crash_base > dma32_phys_limit - crash_low_size) &&
> + crash_low_size && reserve_crashkernel_low(crash_low_size)) {
nit: The line above should be aligned one character to the left
(remove one space in the indent).
> + memblock_phys_free(crash_base, crash_size);
> + return;
> }
>
> pr_info("crashkernel: reserved 0x%016llx - 0x%016llx (%lld MB)\n",
...
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH -next 2/2] docs: kdump: Update the crashkernel description for riscv
On Tue, Mar 21, 2023 at 04:42:44AM +0800, Chen Jiahao wrote: > Now "crashkernel=" parameter on riscv has been updated to support > crashkernel=X,[high,low]. Through which we can reserve memory region > above/within 32bit addressible DMA zone. > > Here update the parameter description accordingly. > > Signed-off-by: Chen Jiahao Reviewed-by: Simon Horman ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2 2/2] LoongArch: kdump: Set up kernel image segment
On Sat, Mar 04, 2023 at 11:09:11AM +0800, Youling Tang wrote:
> On LoongArch, we can use the same kernel image as 1st kernel when
> 3f89765d622 ("LoongArch: kdump: Add single kernel image implementation")
> is merged, but we have to modify the entry point as well as segments
> addresses in the kernel elf header (or PE format vmlinux.efi) in order
> to load them into correct places.
>
> Signed-off-by: Youling Tang
Thanks, applied.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2 1/2] kexec: __NR_kexec_file_load is set to undefined on LoongArch
On Sat, Mar 04, 2023 at 11:09:10AM +0800, Youling Tang wrote:
> The initial reason is that after the merger of 29fe5067ed07 ("kexec: make
> -a the default"), kexec cannot be used on LoongArch architectures. We need
> to add "-c" for normal use. The current kexec_file_load system call is not
> implemented in architectures such as LoongArch, so it needs to pass
> kexec_load.
> So we need to set __NR_kexec_file_load to undefined in unsupported
> architectures.
> This will return EFALLBACK via is_kexec_file_load_implemented, and then via
> kexec_load.
>
> Signed-off-by: Youling Tang
Thanks, applied.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v4] arm64: kdump: simplify the reservation behaviour of crashkernel=,high
On Mon, Mar 06, 2023 at 04:41:24PM +0800, Baoquan He wrote: > On arm64, reservation for 'crashkernel=xM,high' is taken by searching for > suitable memory region top down. If the 'xM' of crashkernel high memory > is reserved from high memory successfully, it will try to reserve > crashkernel low memory later accoringly. Otherwise, it will try to search > low memory area for the 'xM' suitable region. Please see the details in > Documentation/admin-guide/kernel-parameters.txt. > > While we observed an unexpected case where a reserved region crosses the > high and low meomry boundary. E.g on a system with 4G as low memory end, > user added the kernel parameters like: 'crashkernel=512M,high', it could > finally have [4G-126M, 4G+386M], [1G, 1G+128M] regions in running kernel. > The crashkernel high region crossing low and high memory boudary will bring > issues: > > 1) For crashkernel=x,high, if getting crashkernel high region across > low and high memory boundary, then user will see two memory regions in > low memory, and one memory region in high memory. The two crashkernel > low memory regions are confusing as shown in above example. > > 2) If people explicityly specify "crashkernel=x,high crashkernel=y,low" > and y <= 128M, when crashkernel high region crosses low and high memory > boundary and the part of crashkernel high reservation below boundary is > bigger than y, the expected crahskernel low reservation will be skipped. > But the expected crashkernel high reservation is shrank and could not > satisfy user space requirement. > > 3) The crossing boundary behaviour of crahskernel high reservation is > different than x86 arch. On x86_64, the low memory end is 4G fixedly, > and the memory near 4G is reserved by system, e.g for mapping firmware, > pci mapping, so the crashkernel reservation crossing boundary never happens. > >From distros point of view, this brings inconsistency and confusion. Users > need to dig into x86 and arm64 system details to find out why. > > For kernel itself, the impact of issue 3) could be slight. While issue > 1) and 2) cause actual impact because it brings obscure semantics and > behaviour to crashkernel=,high reservation. > > Here, for crashkernel=xM,high, search the high memory for the suitable > region only in high memory. If failed, try reserving the suitable > region only in low memory. Like this, the crashkernel high region will > only exist in high memory, and crashkernel low region only exists in low > memory. The reservation behaviour for crashkernel=,high is clearer and > simpler. > > Note: On arm64, the high and low memory boudary could be 1G if it's RPi4 > system, or 4G if other normal systems. > > Signed-off-by: Baoquan He Reviewed-by: Simon Horman ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2 2/2] kexec: Remove unnecessary arch_kexec_kernel_image_load()
On Tue, Mar 07, 2023 at 04:44:16PM -0600, Bjorn Helgaas wrote: > From: Bjorn Helgaas > > arch_kexec_kernel_image_load() only calls kexec_image_load_default(), and > there are no arch-specific implementations. > > Remove the unnecessary arch_kexec_kernel_image_load() and make > kexec_image_load_default() static. > > No functional change intended. > > Signed-off-by: Bjorn Helgaas Reviewed-by: Simon Horman ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2 1/2] x86/kexec: Remove unnecessary arch_kexec_kernel_image_load()
On Tue, Mar 07, 2023 at 04:44:15PM -0600, Bjorn Helgaas wrote: > From: Bjorn Helgaas > > The x86 implementation of arch_kexec_kernel_image_load() is functionally > identical to the generic arch_kexec_kernel_image_load(): > > arch_kexec_kernel_image_load# x86 > if (!image->fops || !image->fops->load) > return ERR_PTR(-ENOEXEC); > return image->fops->load(image, image->kernel_buf, ...) > > arch_kexec_kernel_image_load# generic > kexec_image_load_default > if (!image->fops || !image->fops->load) > return ERR_PTR(-ENOEXEC); > return image->fops->load(image, image->kernel_buf, ...) > > Remove the x86-specific version and use the generic > arch_kexec_kernel_image_load(). No functional change intended. > > Signed-off-by: Bjorn Helgaas Reviewed-by: Simon Horman ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] ppc64: Add elf-ppc64 file types/options and an arch specific flag to man page
On Wed, Mar 01, 2023 at 03:58:19AM -0500, Gautam Menghani wrote: > Document the elf-ppc64 file options and the "--dt-no-old-root" arch > specific flag in the man page. > > Signed-off-by: Gautam Menghani Thanks, applied. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] x86: add devicetree support
On Thu, Feb 23, 2023 at 07:01:07AM +0100, Julian Winkler wrote: > Since linux kernel has dropped support for simple firmware interface > (SFI), the only way of boot newer versions on intel MID platform is > using devicetree > > Signed-off-by: Julian Winkler > --- > V2: added Signed-off-by to commit message Thanks, applied. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] x86: add devicetree support
On Sun, Feb 19, 2023 at 11:18:13AM +0100, Julian Winkler wrote: > Since linux kernel has dropped support for simple firmware interface > (SFI), the only way of boot newer versions on intel MID platform is > using devicetree Thanks Julian, in general this patch looks fine to me. Could I ask you to post a v2 that: 1. Is rebased on main - there was some fuzz in kexec-bzImage.c when applying this patch locally. 2. Include a Signed-off-by line. See "Sign your work - the Developer’s Certificate of Origin" in https://www.kernel.org/doc/html/v6.2/process/submitting-patches.html ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] kexec: make -a the default
On Fri, Feb 03, 2023 at 12:10:18AM +0100, Ahelenia Ziemiańska wrote: > AFAICT, there's no downside to this, and running into this each time > I want to kexec (and, presumably, a significant chunk of the population, > since lockdown is quite popular) on some machines, > then going to the manual, then finding out I want the /auto/ flag(!) > is quite annoying: > # kexec -l /boot/vmlinuz-6.1.0-3-amd64 --initrd > /boot/initrd.img-6.1.0-3-amd64 --reuse-cmdline > kexec_load failed: Operation not permitted > entry = 0x46eff7760 flags = 0x3e > nr_segments = 7 > segment[0].buf = 0x557cd303efa0 > segment[0].bufsz = 0x70 > segment[0].mem = 0x10 > segment[0].memsz = 0x1000 > segment[1].buf = 0x557cd3046fe0 > segment[1].bufsz = 0x190 > segment[1].mem = 0x101000 > segment[1].memsz = 0x1000 > segment[2].buf = 0x557cd303f6e0 > segment[2].bufsz = 0x30 > segment[2].mem = 0x102000 > segment[2].memsz = 0x1000 > segment[3].buf = 0x7f658fa37010 > segment[3].bufsz = 0x12a51b5 > segment[3].mem = 0x46a55a000 > segment[3].memsz = 0x12a6000 > segment[4].buf = 0x7f6590ce1210 > segment[4].bufsz = 0x7e99e0 > segment[4].mem = 0x46b80 > segment[4].memsz = 0x377c000 > segment[5].buf = 0x557cd3039350 > segment[5].bufsz = 0x42fa > segment[5].mem = 0x46eff2000 > segment[5].memsz = 0x5000 > segment[6].buf = 0x557cd3032000 > segment[6].bufsz = 0x70e0 > segment[6].mem = 0x46eff7000 > segment[6].memsz = 0x9000 > > Closes: https://bugs.debian.org/1030248 > Signed-off-by: Ahelenia Ziemiańska Thanks, applied. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] ppc64: add --reuse-cmdline parameter support
On Wed, Feb 01, 2023 at 02:23:31PM +0530, Sourabh Jain wrote: > An option to copy the command line arguments from running kernel > to kexec'd kernel. This option works for both kexec and kdump. > > In case --append= or --command-line= is provided along > with --reuse-cmdline parameter then args listed against append and > command-line parameter will be combined with command line argument > from running kernel. > > Signed-off-by: Sourabh Jain Thanks, applied. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 1/2] arm64: kdump: simplify the reservation behaviour of crashkernel=,high
On Tue, Jan 17, 2023 at 11:49:20AM +0800, Baoquan He wrote:
> On arm64, reservation for 'crashkernel=xM,high' is taken by searching for
> suitable memory region up down. If the 'xM' of crashkernel high memory
> is reserved from high memory successfully, it will try to reserve
> crashkernel low memory later accoringly. Otherwise, it will try to search
> low memory area for the 'xM' suitable region.
>
> While we observed an unexpected case where a reserved region crosses the
> high and low meomry boundary. E.g on a system with 4G as low memory end,
> user added the kernel parameters like: 'crashkernel=512M,high', it could
> finally have [4G-126M, 4G+386M], [1G, 1G+128M] regions in running kernel.
> This looks very strange because we have two low memory regions
> [4G-126M, 4G] and [1G, 1G+128M]. Much explanation need be given to tell
> why that happened.
>
> Here, for crashkernel=xM,high, search the high memory for the suitable
> region above the high and low memory boundary. If failed, try reserving
> the suitable region below the boundary. Like this, the crashkernel high
> region will only exist in high memory, and crashkernel low region only
> exists in low memory. The reservation behaviour for crashkernel=,high is
> clearer and simpler.
>
> Signed-off-by: Baoquan He
> ---
> arch/arm64/mm/init.c | 30 +++---
> 1 file changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 58a0bb2c17f1..26a05af2bfa8 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -127,12 +127,13 @@ static int __init reserve_crashkernel_low(unsigned long
> long low_size)
> */
> static void __init reserve_crashkernel(void)
> {
> - unsigned long long crash_base, crash_size;
> - unsigned long long crash_low_size = 0;
> + unsigned long long crash_base, crash_size, search_base;
> unsigned long long crash_max = CRASH_ADDR_LOW_MAX;
> + unsigned long long crash_low_size = 0;
> char *cmdline = boot_command_line;
> - int ret;
> bool fixed_base = false;
> + bool high = false;
> + int ret;
>
> if (!IS_ENABLED(CONFIG_KEXEC_CORE))
> return;
> @@ -155,7 +156,9 @@ static void __init reserve_crashkernel(void)
> else if (ret)
> return;
>
> + search_base = CRASH_ADDR_LOW_MAX;
> crash_max = CRASH_ADDR_HIGH_MAX;
> + high = true;
> } else if (ret || !crash_size) {
> /* The specified value is invalid */
> return;
> @@ -166,31 +169,44 @@ static void __init reserve_crashkernel(void)
> /* User specifies base address explicitly. */
> if (crash_base) {
> fixed_base = true;
> + search_base = crash_base;
> crash_max = crash_base + crash_size;
> }
>
> retry:
> crash_base = memblock_phys_alloc_range(crash_size, CRASH_ALIGN,
> -crash_base, crash_max);
> +search_base, crash_max);
> if (!crash_base) {
> + if (fixed_base) {
> + pr_warn("cannot reserve crashkernel region
> [0x%llx-0x%llx]\n",
> + search_base, crash_max);
> + return;
> + }
> +
> /*
>* If the first attempt was for low memory, fall back to
>* high memory, the minimum required low memory will be
>* reserved later.
>*/
> - if (!fixed_base && (crash_max == CRASH_ADDR_LOW_MAX)) {
> + if (!high && crash_max == CRASH_ADDR_LOW_MAX) {
> crash_max = CRASH_ADDR_HIGH_MAX;
> + search_base = CRASH_ADDR_LOW_MAX;
> crash_low_size = DEFAULT_CRASH_KERNEL_LOW_SIZE;
> goto retry;
> }
>
> + if (high && (crash_max == CRASH_ADDR_HIGH_MAX)) {
nit: unnecessary (and inconsistent with code just above) parentheses.
> + crash_max = CRASH_ADDR_LOW_MAX;
> + search_base = 0;
> + goto retry;
> + }
> pr_warn("cannot allocate crashkernel (size:0x%llx)\n",
> crash_size);
> return;
> }
>
> - if ((crash_base > CRASH_ADDR_LOW_MAX - crash_low_size) &&
> - crash_low_size && reserve_crashkernel_low(crash_low_size)) {
> + if ((crash_base >= CRASH_ADDR_LOW_MAX) && crash_low_size &&
> + reserve_crashkernel_low(crash_low_size)) {
> memblock_phys_free(crash_base, crash_size);
> return;
> }
> --
> 2.34.1
>
>
> ___
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>
___
kexec mailing
Re: [PATCH 2/2] arm64/kdump: add code comments for crashkernel reservation cases
On Tue, Jan 17, 2023 at 11:49:21AM +0800, Baoquan He wrote:
> This will help understand codes on crashkernel reservations on arm64.
FWIIW, I think you can fold this into the first patch.
And, although I have no good idea at this moment, I do wonder
if the logic can be simplified - I for one really needed the
comments to understand the retry logic.
> Signed-off-by: Baoquan He
> ---
> arch/arm64/mm/init.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 26a05af2bfa8..f88ad17cb20d 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -177,6 +177,10 @@ static void __init reserve_crashkernel(void)
> crash_base = memblock_phys_alloc_range(crash_size, CRASH_ALIGN,
> search_base, crash_max);
> if (!crash_base) {
> + /*
> + * For crashkernel=size[KMG]@offset[KMG], print out failure
> + * message if can't reserve the specified region.
> + */
> if (fixed_base) {
> pr_warn("cannot reserve crashkernel region
> [0x%llx-0x%llx]\n",
> search_base, crash_max);
> @@ -188,6 +192,11 @@ static void __init reserve_crashkernel(void)
>* high memory, the minimum required low memory will be
>* reserved later.
>*/
> + /*
> + * For crashkernel=size[KMG], if the first attempt was for
> + * low memory, fall back to high memory, the minimum required
> + * low memory will be reserved later.
> + */
I think this duplicates the preceding comment.
Perhaps just replace the earlier comment with this one.
> if (!high && crash_max == CRASH_ADDR_LOW_MAX) {
> crash_max = CRASH_ADDR_HIGH_MAX;
> search_base = CRASH_ADDR_LOW_MAX;
> @@ -195,6 +204,10 @@ static void __init reserve_crashkernel(void)
> goto retry;
> }
>
> + /*
> + * For crashkernel=size[KMG],high, if the first attempt was for
> + * high memory, fall back to low memory.
> + */
> if (high && (crash_max == CRASH_ADDR_HIGH_MAX)) {
> crash_max = CRASH_ADDR_LOW_MAX;
> search_base = 0;
> --
> 2.34.1
>
>
> ___
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[ANNOUNCE] kexec-tools 2.0.26
Hi all, I am happy to announce the release of kexec-tools 2.0.26. This is a feature release coinciding with the release of v6.1 of the Linux Kernel. This release can be downloaded from kernel.org: http://kernel.org/pub/linux/utils/kernel/kexec/kexec-tools-2.0.26.tar.xz http://kernel.org/pub/linux/utils/kernel/kexec/ It is also tagged it in git: git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git Thanks to everyone who has contributed to kexec! Commits since v2.0.25: ae1bd3dde601 kexec-tools 2.0.26 ffb186b83420 kexec-tools 2.0.26-rc1 b9de05184816 m68k: pass rng seed via BI_RNG_SEED b0381b817910 workflow: update to checkout@v3 834be38cc044 LoongArch: Remove redundant cmdline parameters when using --reuse-cmdline option 84138f41efd5 LoongArch: Add purgatory framework code 615b6757dcab LoongArch: PE format image loading support 1c8bf2dc0127 LoongArch: Add kexec/kdump support dceb1d8926e6 config: Add LoongArch architecture support in config.guess and config.sub files 6b6187f546f0 ppc64: remove rma_top limit bc38df5e8e24 kexec-tools 2.0.25.git ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[ANNOUNCE] kexec-tools 2.0.26-rc1
Hi all, I am happy to announce the release of kexec-tools 2.0.26-rc1. This is an incremental feature pre-release. So long as no serious problems arise I intend to release kexec-tools 2.0.26 in a weeks time. Testing of 2.0.26-rc1 would be greatly appreciated. I do not have any outstanding changes for 2.0.26 at this time. And I would like to only accept bug fixes at this time and take features patches once 2.0.26 has been released. The pre-release can be downloaded from kernel.org: https://kernel.org/pub/linux/utils/kernel/kexec/kexec-tools-2.0.26-rc1.tar.xz https://kernel.org/pub/linux/utils/kernel/kexec/ I have also tagged it in git: https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git Thanks to everyone who has contributed to kexec. For reference the changes since v2.0.25 are: ffb186b83420 kexec-tools 2.0.26-rc1 b9de05184816 m68k: pass rng seed via BI_RNG_SEED b0381b817910 workflow: update to checkout@v3 834be38cc044 LoongArch: Remove redundant cmdline parameters when using --reuse-cmdline option 84138f41efd5 LoongArch: Add purgatory framework code 615b6757dcab LoongArch: PE format image loading support 1c8bf2dc0127 LoongArch: Add kexec/kdump support dceb1d8926e6 config: Add LoongArch architecture support in config.guess and config.sub files 6b6187f546f0 ppc64: remove rma_top limit bc38df5e8e24 kexec-tools 2.0.25.git ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[ANNOUNCE] kexec-tools v2.0.26 preparation
Hi all, I am planning to release kexec-tools v2.0.26 in the next two weeks to roughly coincide with the release of the v6.1 kernel. I would like to ask interested parties to send any patches they would like included in v2.0.26 within one week so they can be considered for inclusion in an rc release. For reference the patches queued up since v2.0.25 are as follows. Thanks to everyone who has contributed to kexec-tools! b9de05184816 m68k: pass rng seed via BI_RNG_SEED b0381b817910 workflow: update to checkout@v3 834be38cc044 LoongArch: Remove redundant cmdline parameters when using --reuse-cmdline option 84138f41efd5 LoongArch: Add purgatory framework code 615b6757dcab LoongArch: PE format image loading support 1c8bf2dc0127 LoongArch: Add kexec/kdump support dceb1d8926e6 config: Add LoongArch architecture support in config.guess and config.sub files 6b6187f546f0 ppc64: remove rma_top limit bc38df5e8e24 kexec-tools 2.0.25.git ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH kexec-tools v3] m68k: pass rng seed via BI_RNG_SEED
On Mon, Nov 14, 2022 at 04:43:03PM +0100, Jason A. Donenfeld wrote: > In order to pass fresh entropy to kexec'd kernels, use BI_RNG_SEED > for passing a seed, with the same semantics that kexec-tools currently > uses for i386's setup_data. > > Link: https://git.kernel.org/torvalds/c/dc63a086daee92c63e3 > Signed-off-by: Jason A. Donenfeld Thanks Jason, applied. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2 RESEND kexec-tools] m68k: pass rng seed via BI_RNG_SEED
On Fri, Nov 11, 2022 at 02:35:33AM +0100, Jason A. Donenfeld wrote: > In order to pass fresh entropy to kexec'd kernels, use BI_RNG_SEED > for passing a seed, with the same semantics that kexec-tools currently > uses for i386's setup_data. > > Link: https://git.kernel.org/torvalds/c/dc63a086daee92c63e3 > Signed-off-by: Jason A. Donenfeld > --- > Seems like this was forgotten about, so resending. Hi Jason, Sorry about missing this earlier. I was planning to apply it just now, but it seems that the github workflow flagged a problem: In file included from ../../kexec/arch/m68k/kexec-m68k.c:19: ../../kexec/arch/m68k/bootinfo.h:25:4: error: unknown type name ‘u8’ 25 |u8 data[0]; |^~ make[1]: *** [Makefile:124: kexec/arch/m68k/kexec-m68k.o] Error 1 make[1]: *** Waiting for unfinished jobs In file included from ../../kexec/arch/m68k/kexec-elf-m68k.c:27: ../../kexec/arch/m68k/bootinfo.h:25:4: error: unknown type name ‘u8’ 25 |u8 data[0]; |^~ make[1]: *** [Makefile:124: kexec/arch/m68k/kexec-elf-m68k.o] Error 1 make: *** [Makefile:276: distcheck] Error 2 make[1]: Leaving directory '/home/runner/work/kexec-tools/kexec-tools/kexec-tools-2.0.25.git/_build/sub' Error: Process completed with exit code 2. Ref: https://github.com/horms/kexec-tools/actions/runs/3462830642/jobs/5782238446 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH V2] RISC-V: Add support for riscv kexec/kdump on kexec-tools
On Wed, Oct 26, 2022 at 10:13:48AM +0800, Xianting Tian wrote:
> Hi Simon
>
> thanks for the comments
>
> 在 2022/10/21 下午11:27, Simon Horman 写道:
> > On Thu, Oct 20, 2022 at 11:15:48AM +0800, Xianting Tian wrote:
> > > From: Nick Kossifidis
> > >
> > > This patch adds support for loading the ELF kernel image. It parses
> > > the current/provided device tree to determine the system's memory
> > > layout, and /proc/iomem for the various kernel segments.
> > >
> > > This patch was firstly developed by Nick Kossifidis, and two fixes (
> > > 1: fail to find free memory area for dtb load when using initrd image,
> > >lists.infradead.org/pipermail/linux-riscv/2022-August/018398.html;
> > > 2: fix memory range size calculation,
> > > kexec/arch/riscv/crashdump-riscv.c:line 85
> > > ) are contributed by Yixun Lan, Xianting Tian.
> > >
> > > Tested on Qemu's rv64 virt machine and SoC of T-Head RISC-V Xuantie 910
> > > CPU.
> > Hi,
> >
> > thanks for some patch.
> >
> > Some minor feedback follows.
> >
> > Separately, I'll post a patch to add RISC-V builds to the github
> > workflow. If you could include that in V3 I'd be most grateful.
> >
> > > Tested-by: Yixun Lan
> > > Co-developed-by: Xianting Tian
> > > Co-developed-by: Yixun Lan
> > > Signed-off-by: Nick Kossifidis
> > ...
> >
> > > + ret = mem_regions_alloc_and_add(mem_ranges, start,
> > > + end - start, type);
> > mem_regions_alloc_and_add isn't always available.
> > f.e. on mips this causes a build failure.
> >
> > Ref:
> > https://github.com/horms/kexec-tools/actions/runs/3298491143/jobs/5440677595
>
> As you know, mem_regions_sort, mem_regions_alloc_and_add are the common
> funtions,
>
> The build error of mips is caused by this riscv patch?
Yes, I think so.
The workflow passes on main:
https://github.com/horms/kexec-tools/actions/runs/3344523519
But not with the riscv patch applied:
https://github.com/horms/kexec-tools/tree/build-test-riscv-v2
> kexec/mem_regions.c:void mem_regions_sort(struct memory_ranges *ranges)
> kexec/mem_regions.h:void mem_regions_sort(struct memory_ranges *ranges);
>
>
> kexec/mem_regions.c:int mem_regions_alloc_and_add(struct memory_ranges
> *ranges,
> kexec/mem_regions.h:int mem_regions_alloc_and_add(struct memory_ranges
> *ranges,
>
> >
> > ...
> >
> > > +int dtb_get_memory_ranges(char *dtb, struct memory_ranges *mem_ranges,
> > > struct memory_ranges *extra_ranges)
> > > +{
> > ...
> >
> > > + mem_regions_sort(mem_ranges);
> > Likewise, mem_regions_sort isn't always available.
> > f.e. on mips this causes a build failure.
> >
> > ...
> >
> > > diff --git a/purgatory/arch/riscv/Makefile b/purgatory/arch/riscv/Makefile
> > > new file mode 100644
> > > index 000..8bded71
> > > --- /dev/null
> > > +++ b/purgatory/arch/riscv/Makefile
> > > @@ -0,0 +1,7 @@
> > > +#
> > > +# Purgatory riscv
> > > +#
> > > +
> > > +riscv_PURGATORY_SRCS =
> > > +
> > > +dist += purgatory/arch/sh/Makefile $(riscv_PURGATORY_SRCS)
> > s/sh/riscv/
> >
> > Else the distribution tarball won't include this Makefile
> >
> > You can exercise this using:
> >make distcheck DISTCHECK_CONFIGURE_FLAGS="--host=riscv64-linux-gnu"
> thanks, I will fix this.
Thanks.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] workflow: update to checkout@v3
On Fri, Oct 21, 2022 at 05:27:57PM +0200, Simon Horman wrote: > Use to checkout@v3 instead of checkout@v2 > as the latter uses Node.js 12 actions which are deprecated. > > https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/ > > Signed-off-by: Simon Horman Applied ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH kexec-tools] github: add RISC-V to workflow
Add RISC-V builds to workflow Signed-off-by: Simon Horman --- .github/workflows/build.yml | 3 +++ 1 file changed, 3 insertions(+) Hi Xianting Tian, Please consider including this a v3 patch-set to add RISC-V to kexec-tools. diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml index e554751e0017..2731282d9521 100644 --- a/.github/workflows/build.yml +++ b/.github/workflows/build.yml @@ -19,6 +19,8 @@ jobs: - powerpc - powerpc64 - powerpc64le +- riscv32 +- riscv64 - sh4 - s390x - x86_64-x32 @@ -42,6 +44,7 @@ jobs: case $ARCH in arm) GNU_ARCH="arm-linux-gnueabi" ;; arm64) GNU_ARCH="aarch64-linux-gnu" ;; + riscv32) CROSS_COMPILER_PKG="gcc-riscv64-linux-gnu" ;; x86_64) ;; x86_64-x32) GNU_ARCH="x86_64-linux-gnux32" CROSS_COMPILER_PKG="gcc-x86-64-linux-gnux32" ;; -- 2.30.2 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH] workflow: update to checkout@v3
Use to checkout@v3 instead of checkout@v2 as the latter uses Node.js 12 actions which are deprecated. https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/ Signed-off-by: Simon Horman --- .github/workflows/build.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml index 2731282d9521..efa17edc77bf 100644 --- a/.github/workflows/build.yml +++ b/.github/workflows/build.yml @@ -30,7 +30,7 @@ jobs: libxen: libxen steps: - name: Checkout - uses: actions/checkout@v2 + uses: actions/checkout@v3 - name: Set Environment env: -- 2.30.2 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH V2] RISC-V: Add support for riscv kexec/kdump on kexec-tools
On Thu, Oct 20, 2022 at 11:15:48AM +0800, Xianting Tian wrote:
> From: Nick Kossifidis
>
> This patch adds support for loading the ELF kernel image. It parses
> the current/provided device tree to determine the system's memory
> layout, and /proc/iomem for the various kernel segments.
>
> This patch was firstly developed by Nick Kossifidis, and two fixes (
>1: fail to find free memory area for dtb load when using initrd image,
> lists.infradead.org/pipermail/linux-riscv/2022-August/018398.html;
>2: fix memory range size calculation,
>kexec/arch/riscv/crashdump-riscv.c:line 85
> ) are contributed by Yixun Lan, Xianting Tian.
>
> Tested on Qemu's rv64 virt machine and SoC of T-Head RISC-V Xuantie 910 CPU.
Hi,
thanks for some patch.
Some minor feedback follows.
Separately, I'll post a patch to add RISC-V builds to the github
workflow. If you could include that in V3 I'd be most grateful.
>
> Tested-by: Yixun Lan
> Co-developed-by: Xianting Tian
> Co-developed-by: Yixun Lan
> Signed-off-by: Nick Kossifidis
...
> + ret = mem_regions_alloc_and_add(mem_ranges, start,
> + end - start, type);
mem_regions_alloc_and_add isn't always available.
f.e. on mips this causes a build failure.
Ref:
https://github.com/horms/kexec-tools/actions/runs/3298491143/jobs/5440677595
...
> +int dtb_get_memory_ranges(char *dtb, struct memory_ranges *mem_ranges,
> struct memory_ranges *extra_ranges)
> +{
...
> + mem_regions_sort(mem_ranges);
Likewise, mem_regions_sort isn't always available.
f.e. on mips this causes a build failure.
...
> diff --git a/purgatory/arch/riscv/Makefile b/purgatory/arch/riscv/Makefile
> new file mode 100644
> index 000..8bded71
> --- /dev/null
> +++ b/purgatory/arch/riscv/Makefile
> @@ -0,0 +1,7 @@
> +#
> +# Purgatory riscv
> +#
> +
> +riscv_PURGATORY_SRCS =
> +
> +dist += purgatory/arch/sh/Makefile $(riscv_PURGATORY_SRCS)
s/sh/riscv/
Else the distribution tarball won't include this Makefile
You can exercise this using:
make distcheck DISTCHECK_CONFIGURE_FLAGS="--host=riscv64-linux-gnu"
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 0/5] Add LoongArch port support
On Wed, Sep 28, 2022 at 10:28:21AM +0800, Youling Tang wrote: > This patch series to support kexec/kdump (only 64bit). > > Note: Kernel kexec/kdump support patch see link [1]: > Link [1]: > https://lore.kernel.org/loongarch/711d53ae-197f-3c55-d09d-2f40e6886...@loongson.cn/T/#t Thanks, applied for inclusion in the next kexec-tools release. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
