[PATCH v2] LoongArch: Load vmlinux.efi to the link address

[PATCH v2] LoongArch: Load vmlinux.efi to the link address

[WANG Rui]

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@loongson.cn>
---

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__);
-- 
2.42.0


_______________________________________________
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

[Huacai Chen]

Reviewed-by: Huacai Chen <chenhuacai@loongson.cn>

On Sat, Nov 25, 2023 at 2:53 PM WANG Rui <wangrui@loongson.cn> 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@loongson.cn>
> ---
>
> 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__);
> --
> 2.42.0
>

_______________________________________________
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

[RuiRui Yang]

On Sat, 25 Nov 2023 at 14:54, WANG Rui <wangrui@loongson.cn> 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@loongson.cn>
> ---
>
> 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@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 v2] LoongArch: Load vmlinux.efi to the link address

[RuiRui Yang]

On Mon, 27 Nov 2023 at 09:53, RuiRui Yang <ruyang@redhat.com> wrote:
>
> On Sat, 25 Nov 2023 at 14:54, WANG Rui <wangrui@loongson.cn> 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@loongson.cn>
> > ---
> >
> > 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@redhat.com>,
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?
>
> 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@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 v2] LoongArch: Load vmlinux.efi to the link address

[WANG Rui]

Hi,

On Mon, Nov 27, 2023 at 10:36 AM RuiRui Yang <ruyang@redhat.com> wrote:
>
> On Mon, 27 Nov 2023 at 09:53, RuiRui Yang <ruyang@redhat.com> wrote:
> >
> > On Sat, 25 Nov 2023 at 14:54, WANG Rui <wangrui@loongson.cn> 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@loongson.cn>
> > > ---
> > >
> > > 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@redhat.com>,
> 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@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/kexec
> > >
>


-- 
WANG Rui


_______________________________________________
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

[Huacai Chen]

Hi, all,

On Tue, Nov 28, 2023 at 2:27 PM WANG Rui <wangrui@loongson.cn> wrote:
>
> Hi,
>
> On Mon, Nov 27, 2023 at 10:36 AM RuiRui Yang <ruyang@redhat.com> wrote:
> >
> > On Mon, 27 Nov 2023 at 09:53, RuiRui Yang <ruyang@redhat.com> wrote:
> > >
> > > On Sat, 25 Nov 2023 at 14:54, WANG Rui <wangrui@loongson.cn> 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@loongson.cn>
> > > > ---
> > > >
> > > > 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@redhat.com>,
> > 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?
I agree with WANG Rui, this should be fixed in kexec-tools, and
'nomap' is not for such a usage.

Huacai

>
> > >
> > > 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@lists.infradead.org
> > > > http://lists.infradead.org/mailman/listinfo/kexec
> > > >
> >
>
>
> --
> WANG Rui
>

_______________________________________________
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

[Simon Horman]

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 <wangrui@loongson.cn> wrote:
> >
> > Hi,
> >
> > On Mon, Nov 27, 2023 at 10:36 AM RuiRui Yang <ruyang@redhat.com> wrote:
> > >
> > > On Mon, 27 Nov 2023 at 09:53, RuiRui Yang <ruyang@redhat.com> wrote:
> > > >
> > > > On Sat, 25 Nov 2023 at 14:54, WANG Rui <wangrui@loongson.cn> 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@loongson.cn>
> > > > > ---
> > > > >
> > > > > 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@redhat.com>,
> > > 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?
> I agree with WANG Rui, this should be fixed in kexec-tools, and
> 'nomap' is not for such a usage.

Can I confirm that you'd still like this patch applied?

_______________________________________________
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

[Huacai Chen]

Hi, Simon,

On Fri, Dec 1, 2023 at 10:06 PM Simon Horman <horms@kernel.org> 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 <wangrui@loongson.cn> wrote:
> > >
> > > Hi,
> > >
> > > On Mon, Nov 27, 2023 at 10:36 AM RuiRui Yang <ruyang@redhat.com> wrote:
> > > >
> > > > On Mon, 27 Nov 2023 at 09:53, RuiRui Yang <ruyang@redhat.com> wrote:
> > > > >
> > > > > On Sat, 25 Nov 2023 at 14:54, WANG Rui <wangrui@loongson.cn> 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@loongson.cn>
> > > > > > ---
> > > > > >
> > > > > > 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@redhat.com>,
> > > > 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?
> > I agree with WANG Rui, this should be fixed in kexec-tools, and
> > 'nomap' is not for such a usage.
>
> Can I confirm that you'd still like this patch applied?
Yes, v1 breaks the real machine, while v2 works on both real machine and qemu.

Huacai

_______________________________________________
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

[Simon Horman]

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 <horms@kernel.org> 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 <wangrui@loongson.cn> wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Mon, Nov 27, 2023 at 10:36 AM RuiRui Yang <ruyang@redhat.com> wrote:
> > > > >
> > > > > On Mon, 27 Nov 2023 at 09:53, RuiRui Yang <ruyang@redhat.com> wrote:
> > > > > >
> > > > > > On Sat, 25 Nov 2023 at 14:54, WANG Rui <wangrui@loongson.cn> 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@loongson.cn>
> > > > > > > ---
> > > > > > >
> > > > > > > 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@redhat.com>,
> > > > > 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?
> > > I agree with WANG Rui, this should be fixed in kexec-tools, and
> > > 'nomap' is not for such a usage.
> >
> > Can I confirm that you'd still like this patch applied?
> Yes, v1 breaks the real machine, while v2 works on both real machine and qemu.

Thanks, applied.

_______________________________________________
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

[hev]

Hello Simon,

Could you apply this patch (v2) instead of patch (v1) [1] ?
Thanks!

[1] https://lore.kernel.org/kexec/20231124154658.114579-1-wangrui@loongson.cn/

On Sat, Nov 25, 2023 at 2:52 PM WANG Rui <wangrui@loongson.cn> 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@loongson.cn>
> ---
>
> 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__);
> --
> 2.42.0
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec