On Sat, 25 Nov 2023 at 14:54, WANG Rui <wangrui@xxxxxxxxxxx> 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: 0000000000000000 > pei_loongarch_load: kernel_entry: 00000000013f1000 > pei_loongarch_load: image_size: 0000000001ca0000 > pei_loongarch_load: text_offset: 0000000000200000 > pei_loongarch_load: phys_offset: 0000000000000000 > pei_loongarch_load: PE format: yes > loongarch_load_other_segments:333: command_line: kexec console=ttyS0,115200 > kexec_load: entry = 0x13f1000 flags = 0x1020000 > nr_segments = 2 > segment[0].buf = 0x7fffeea38010 > segment[0].bufsz = 0x1b55200 > segment[0].mem = (nil) > segment[0].memsz = 0x1ca0000 > segment[1].buf = 0x5555570940b0 > segment[1].bufsz = 0x200 > segment[1].mem = 0x1ca0000 > 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: 0000000000200000 > pei_loongarch_load: kernel_entry: 00000000013f1000 > pei_loongarch_load: image_size: 0000000001ca0000 > pei_loongarch_load: text_offset: 0000000000200000 > pei_loongarch_load: phys_offset: 0000000000000000 > pei_loongarch_load: PE format: yes > loongarch_load_other_segments:339: command_line: kexec console=ttyS0,115200 > kexec_load: entry = 0x13f1000 flags = 0x1020000 > nr_segments = 2 > segment[0].buf = 0x7ffff2028010 > segment[0].bufsz = 0x1b55200 > segment[0].mem = 0x200000 > segment[0].memsz = 0x1ca0000 > segment[1].buf = 0x555557498098 > segment[1].bufsz = 0x200 > segment[1].mem = 0x1ea0000 > segment[1].memsz = 0x4000 > > Signed-off-by: WANG Rui <wangrui@xxxxxxxxxxx> > --- > > 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 did not send it out. I suspect even if the locate_hole avoids the wrong memory, in the 2nd kernel it could still access it. Correct? Index: linux/arch/loongarch/kernel/mem.c =================================================================== --- linux.orig/arch/loongarch/kernel/mem.c 2023-06-02 10:24:09.633593320 +0800 +++ linux/arch/loongarch/kernel/mem.c 2023-10-05 15:27:05.609455460 +0800 @@ -52,8 +52,8 @@ memblock_set_current_limit(PFN_PHYS(max_low_pfn)); memblock_set_node(0, PHYS_ADDR_MAX, &memblock.memory, 0); - /* Reserve the first 2MB */ - memblock_reserve(PHYS_OFFSET, 0x200000); + /* Mark the first 2MB as nomap */ + memblock_mark_nomap(PHYS_OFFSET, 0x200000); /* Reserve the kernel text/data/bss */ memblock_reserve(__pa_symbol(&_text), > -- > 2.42.0 > > > _______________________________________________ > kexec mailing list > kexec@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/kexec > _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec