On Wed, 14 Aug 2024 at 16:23, Dave Young <dyoung@xxxxxxxxxx> wrote: > > On Mon, 12 Aug 2024 at 22:36, Petr Tesarik <ptesarik@xxxxxxxx> wrote: > > > > Hi, > > > > On Sat, 18 May 2024 09:33:04 +0100 > > Simon Horman <horms@xxxxxxxxxx> wrote: > > > > > On Sat, May 18, 2024 at 11:39:18AM +0800, Dave Young wrote: > > > > On Wed, 11 Oct 2023 at 13:24, Song Shuai <songshuaishuai@xxxxxxxxxxx> wrote: > > > > > > > > > > > > > > > > > > > > 在 2023/9/20 19:56, Simon Horman 写道: > > > > > > 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? > > > > > > > > > > Hi, Simon and Nick: > > > > > > > > > > I squashed the first four patches as a "RISC-V: Some fixes for riscv > > > > > port" patch and then took the horms/main as the base to collect the 2 > > > > > patches from horms/build-test-riscv-v2 branch and this series togother. > > > > > These are the Github link and all commits for RISC-V. > > > > > > > > > > https://github.com/sugarfillet/kexec-tools/commits/main_rv > > > > > > > > > > 5dc133e RISC-V: Support loading Image binary file > > > > > b042f6d RISC-V: Separate elf_riscv_find_pbase out > > > > > 8f344c7 RISC-V: Enable kexec_file_load syscall > > > > > 7d4b982 RISC-V: Some fixes for riscv port > > > > > 3205c1c local: RISC-V: distribute purgatory/riscv/Makefile > > > > > 54f9daf RISC-V: Add support for riscv kexec/kdump on kexec-tools > > > > > > > > > > Since I didn't found the issues/fixes as Nick mentioned with these > > > > > commits, I prefer to merge them into horms/main and let more kexec/kdump > > > > > users to help improve/fixup RISC-V port. > > > > > > > > Hi, I noticed another pr for Fedora kexec-tools: > > > > https://src.fedoraproject.org/rpms/kexec-tools/pull-request/24 > > > > > > > > It is bad to take it as Fedora only, I would suggest posting all the > > > > refreshed patches together here again for review. > > > > > > > > If no enough reviewers can review them my another suggestion is to > > > > drop the kexec_load support code for the time being, and only enable > > > > the kexec_file_load support code in kexec-tools, and I assume below > > > > kernel commit make the kexec_file_load kernel piece of work done. > > > > Then it will be easier to review and make something working at least. > > > > commit 6261586e0c91db14c34f894f4bc48f2300cff1d4 > > > > Author: Liao Chang <liaochang1@xxxxxxxxxx> > > > > Date: Fri Apr 8 18:09:11 2022 +0800 > > > > > > > > RISC-V: Add kexec_file support > > > > > > Hi, > > > > > > I would gladly take a patchset for kexec-tools that adds RISC-V support in > > > a coherent manner. > > > > Have I missed some progress on this topic? FWIW I can take care of > > RISC-V support in kexec-tools, I even received a VisionFive 2 board > > from RVI last year specifically to help with kexec. > > > > I merely don't want to duplicate efforts or "steal" someone else's > > project. Is RISC-V support in kexec-tools an orphaned project now? > > > > I thought about a simple kexec_file_load only approach previously but > I have no time to work on it actually. In theory I think a simple > kexec_file_load implementation should only share some common functions > eg. arguments parsing, file reading etc. and load the kernel and > initrd into memory, pass the fds and cmdline buffer into kernel, > that's all, Even no need to have the arch specific file format > checking as they should have been done in the related kernel code. > But looking at the code it is not easy. Currently the kexec_load and > kexec_file_load implementations are not logically separate in the code > and the cleanup is hard. Hi, My concept is like below (an ugly draft, not polished and well tested, also missing zboot/uki decompressing), maybe people can use it temporarily before a full support code is ready: https://github.com/daveyoung/kexecfile Thanks Dave
