* [PATCH v2] LoongArch: Load vmlinux.efi to the link address
@ 2023-11-25 6:52 WANG Rui
2023-11-26 3:28 ` Huacai Chen
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: WANG Rui @ 2023-11-25 6:52 UTC (permalink / raw)
To: kexec; +Cc: Huacai Chen, hev, 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
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH v2] LoongArch: Load vmlinux.efi to the link address
2023-11-25 6:52 [PATCH v2] LoongArch: Load vmlinux.efi to the link address WANG Rui
@ 2023-11-26 3:28 ` Huacai Chen
2023-11-27 1:53 ` RuiRui Yang
2023-11-28 7:07 ` hev
2 siblings, 0 replies; 10+ messages in thread
From: Huacai Chen @ 2023-11-26 3:28 UTC (permalink / raw)
To: WANG Rui; +Cc: kexec, hev
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] LoongArch: Load vmlinux.efi to the link address
2023-11-25 6:52 [PATCH v2] LoongArch: Load vmlinux.efi to the link address WANG Rui
2023-11-26 3:28 ` Huacai Chen
@ 2023-11-27 1:53 ` RuiRui Yang
2023-11-27 2:36 ` RuiRui Yang
2023-11-28 7:07 ` hev
2 siblings, 1 reply; 10+ messages in thread
From: RuiRui Yang @ 2023-11-27 1:53 UTC (permalink / raw)
To: WANG Rui; +Cc: kexec, Huacai Chen, hev
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] LoongArch: Load vmlinux.efi to the link address
2023-11-27 1:53 ` RuiRui Yang
@ 2023-11-27 2:36 ` RuiRui Yang
2023-11-28 6:29 ` WANG Rui
0 siblings, 1 reply; 10+ messages in thread
From: RuiRui Yang @ 2023-11-27 2:36 UTC (permalink / raw)
To: WANG Rui; +Cc: kexec, Huacai Chen, hev
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] LoongArch: Load vmlinux.efi to the link address
2023-11-27 2:36 ` RuiRui Yang
@ 2023-11-28 6:29 ` WANG Rui
2023-11-29 4:15 ` Huacai Chen
0 siblings, 1 reply; 10+ messages in thread
From: WANG Rui @ 2023-11-28 6:29 UTC (permalink / raw)
To: Dave Young; +Cc: RuiRui Yang, kexec, Huacai Chen
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] LoongArch: Load vmlinux.efi to the link address
2023-11-25 6:52 [PATCH v2] LoongArch: Load vmlinux.efi to the link address WANG Rui
2023-11-26 3:28 ` Huacai Chen
2023-11-27 1:53 ` RuiRui Yang
@ 2023-11-28 7:07 ` hev
2 siblings, 0 replies; 10+ messages in thread
From: hev @ 2023-11-28 7:07 UTC (permalink / raw)
To: Simon Horman; +Cc: kexec, Huacai Chen
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] LoongArch: Load vmlinux.efi to the link address
2023-11-28 6:29 ` WANG Rui
@ 2023-11-29 4:15 ` Huacai Chen
2023-12-01 14:06 ` Simon Horman
0 siblings, 1 reply; 10+ messages in thread
From: Huacai Chen @ 2023-11-29 4:15 UTC (permalink / raw)
To: WANG Rui; +Cc: Dave Young, RuiRui Yang, kexec
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] LoongArch: Load vmlinux.efi to the link address
2023-11-29 4:15 ` Huacai Chen
@ 2023-12-01 14:06 ` Simon Horman
2023-12-01 14:54 ` Huacai Chen
0 siblings, 1 reply; 10+ messages in thread
From: Simon Horman @ 2023-12-01 14:06 UTC (permalink / raw)
To: Huacai Chen; +Cc: WANG Rui, Dave Young, RuiRui Yang, kexec
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] LoongArch: Load vmlinux.efi to the link address
2023-12-01 14:06 ` Simon Horman
@ 2023-12-01 14:54 ` Huacai Chen
2023-12-01 16:30 ` Simon Horman
0 siblings, 1 reply; 10+ messages in thread
From: Huacai Chen @ 2023-12-01 14:54 UTC (permalink / raw)
To: Simon Horman; +Cc: WANG Rui, Dave Young, RuiRui Yang, kexec
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] LoongArch: Load vmlinux.efi to the link address
2023-12-01 14:54 ` Huacai Chen
@ 2023-12-01 16:30 ` Simon Horman
0 siblings, 0 replies; 10+ messages in thread
From: Simon Horman @ 2023-12-01 16:30 UTC (permalink / raw)
To: Huacai Chen; +Cc: WANG Rui, Dave Young, RuiRui Yang, kexec
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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2023-12-01 16:30 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-11-25 6:52 [PATCH v2] LoongArch: Load vmlinux.efi to the link address WANG Rui
2023-11-26 3:28 ` Huacai Chen
2023-11-27 1:53 ` RuiRui Yang
2023-11-27 2:36 ` RuiRui Yang
2023-11-28 6:29 ` WANG Rui
2023-11-29 4:15 ` Huacai Chen
2023-12-01 14:06 ` Simon Horman
2023-12-01 14:54 ` Huacai Chen
2023-12-01 16:30 ` Simon Horman
2023-11-28 7:07 ` hev
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox