Hi,
On Mon, Nov 27, 2023 at 10:36 AM RuiRui Yang <ruyang@xxxxxxxxxx> wrote:
>
> On Mon, 27 Nov 2023 at 09:53, RuiRui Yang <ruyang@xxxxxxxxxx> wrote:
> >
> > 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
>
> 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 <dyoung@xxxxxxxxxx>,
> 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 still access it. Correct?
I can confirm that the mapping of the 1st 2M in iomem on qemu causes
kexec to not work. The root cause is that LoongArch's vmlinux.efi can
only run on the link address, which is why I limit the allocation
location of the kernel segment through hole min/max, not the kernel's
iomem.
Hucai, what do you think about the 1st 2M mapping type in the kernel?
> >
> > 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
> > >
>
--
WANG Rui
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
