Re: [PATCH v2] LoongArch: Load vmlinux.efi to the link address
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 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 wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Mon, Nov 27, 2023 at 10:36 AM RuiRui Yang wrote:
> > > > >
> > > > > On Mon, 27 Nov 2023 at 09:53, RuiRui Yang wrote:
> > > > > >
> > > > > > On Sat, 25 Nov 2023 at 14:54, WANG Rui 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:
> > > > > > > pei_loongarch_load: kernel_entry: 013f1000
> > > > > > > pei_loongarch_load: image_size: 01ca
> > > > > > > pei_loongarch_load: text_offset:0020
> > > > > > > pei_loongarch_load: phys_offset:
> > > > > > > pei_loongarch_load: PE format: yes
> > > > > > > loongarch_load_other_segments:333: command_line: kexec
> > > > > > > console=ttyS0,115200
> > > > > > > kexec_load: entry = 0x13f1000 flags = 0x102
> > > > > > > nr_segments = 2
> > > > > > > segment[0].buf = 0x7fffeea38010
> > > > > > > segment[0].bufsz = 0x1b55200
> > > > > > > segment[0].mem = (nil)
> > > > > > > segment[0].memsz = 0x1ca
> > > > > > > segment[1].buf = 0x570940b0
> > > > > > > segment[1].bufsz = 0x200
> > > > > > > segment[1].mem = 0x1ca
> > > > > > > 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: 0020
> > > > > > > pei_loongarch_load: kernel_entry: 013f1000
> > > > > > > pei_loongarch_load: image_size: 01ca
> > > > > > > pei_loongarch_load: text_offset:0020
> > > > > > > pei_loongarch_load: phys_offset:
> > > > > > > pei_loongarch_load: PE format: yes
> > > > > > > loongarch_load_other_segments:339: command_line: kexec
> > > > > > > console=ttyS0,115200
> > > > > > > kexec_load: entry = 0x13f1000 flags = 0x102
> > > > > > > nr_segments = 2
> > > > > > > segment[0].buf = 0x72028010
> > > > > > > segment[0].bufsz = 0x1b55200
> > > > > > > segment[0].mem = 0x20
> > > > > > > segment[0].memsz = 0x1ca
> > > > > > > segment[1].buf = 0x57498098
> > > > > > > segment[1].bufsz = 0x200
> > > > > > > segment[1].mem = 0x1ea
> > > > > > > segment[1].memsz = 0x4000
> > > > > > >
> > > > > > > Signed-off-by: WANG Rui
> > > > > > > ---
> > > > > > >
> > > > > > > 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
Re: [PATCH v2] LoongArch: Load vmlinux.efi to the link address
Hi, Simon,
On Fri, Dec 1, 2023 at 10:06 PM Simon Horman 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 wrote:
> > >
> > > Hi,
> > >
> > > On Mon, Nov 27, 2023 at 10:36 AM RuiRui Yang wrote:
> > > >
> > > > On Mon, 27 Nov 2023 at 09:53, RuiRui Yang wrote:
> > > > >
> > > > > On Sat, 25 Nov 2023 at 14:54, WANG Rui 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:
> > > > > > pei_loongarch_load: kernel_entry: 013f1000
> > > > > > pei_loongarch_load: image_size: 01ca
> > > > > > pei_loongarch_load: text_offset:0020
> > > > > > pei_loongarch_load: phys_offset:
> > > > > > pei_loongarch_load: PE format: yes
> > > > > > loongarch_load_other_segments:333: command_line: kexec
> > > > > > console=ttyS0,115200
> > > > > > kexec_load: entry = 0x13f1000 flags = 0x102
> > > > > > nr_segments = 2
> > > > > > segment[0].buf = 0x7fffeea38010
> > > > > > segment[0].bufsz = 0x1b55200
> > > > > > segment[0].mem = (nil)
> > > > > > segment[0].memsz = 0x1ca
> > > > > > segment[1].buf = 0x570940b0
> > > > > > segment[1].bufsz = 0x200
> > > > > > segment[1].mem = 0x1ca
> > > > > > 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: 0020
> > > > > > pei_loongarch_load: kernel_entry: 013f1000
> > > > > > pei_loongarch_load: image_size: 01ca
> > > > > > pei_loongarch_load: text_offset:0020
> > > > > > pei_loongarch_load: phys_offset:
> > > > > > pei_loongarch_load: PE format: yes
> > > > > > loongarch_load_other_segments:339: command_line: kexec
> > > > > > console=ttyS0,115200
> > > > > > kexec_load: entry = 0x13f1000 flags = 0x102
> > > > > > nr_segments = 2
> > > > > > segment[0].buf = 0x72028010
> > > > > > segment[0].bufsz = 0x1b55200
> > > > > > segment[0].mem = 0x20
> > > > > > segment[0].memsz = 0x1ca
> > > > > > segment[1].buf = 0x57498098
> > > > > > segment[1].bufsz = 0x200
> > > > > > segment[1].mem = 0x1ea
> > > > > > segment[1].memsz = 0x4000
> > > > > >
> > > > > > Signed-off-by: WANG Rui
> > > > > > ---
> > > > > >
> > > > > > 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 ,
> > > > same
Re: [PATCH v2] LoongArch: Load vmlinux.efi to the link address
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 wrote:
> >
> > Hi,
> >
> > On Mon, Nov 27, 2023 at 10:36 AM RuiRui Yang wrote:
> > >
> > > On Mon, 27 Nov 2023 at 09:53, RuiRui Yang wrote:
> > > >
> > > > On Sat, 25 Nov 2023 at 14:54, WANG Rui 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:
> > > > > pei_loongarch_load: kernel_entry: 013f1000
> > > > > pei_loongarch_load: image_size: 01ca
> > > > > pei_loongarch_load: text_offset:0020
> > > > > pei_loongarch_load: phys_offset:
> > > > > pei_loongarch_load: PE format: yes
> > > > > loongarch_load_other_segments:333: command_line: kexec
> > > > > console=ttyS0,115200
> > > > > kexec_load: entry = 0x13f1000 flags = 0x102
> > > > > nr_segments = 2
> > > > > segment[0].buf = 0x7fffeea38010
> > > > > segment[0].bufsz = 0x1b55200
> > > > > segment[0].mem = (nil)
> > > > > segment[0].memsz = 0x1ca
> > > > > segment[1].buf = 0x570940b0
> > > > > segment[1].bufsz = 0x200
> > > > > segment[1].mem = 0x1ca
> > > > > 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: 0020
> > > > > pei_loongarch_load: kernel_entry: 013f1000
> > > > > pei_loongarch_load: image_size: 01ca
> > > > > pei_loongarch_load: text_offset:0020
> > > > > pei_loongarch_load: phys_offset:
> > > > > pei_loongarch_load: PE format: yes
> > > > > loongarch_load_other_segments:339: command_line: kexec
> > > > > console=ttyS0,115200
> > > > > kexec_load: entry = 0x13f1000 flags = 0x102
> > > > > nr_segments = 2
> > > > > segment[0].buf = 0x72028010
> > > > > segment[0].bufsz = 0x1b55200
> > > > > segment[0].mem = 0x20
> > > > > segment[0].memsz = 0x1ca
> > > > > segment[1].buf = 0x57498098
> > > > > segment[1].bufsz = 0x200
> > > > > segment[1].mem = 0x1ea
> > > > > segment[1].memsz = 0x4000
> > > > >
> > > > > Signed-off-by: WANG Rui
> > > > > ---
> > > > >
> > > > > 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 ,
> > > 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
Re: [PATCH v2] LoongArch: Load vmlinux.efi to the link address
Hi, all,
On Tue, Nov 28, 2023 at 2:27 PM WANG Rui wrote:
>
> Hi,
>
> On Mon, Nov 27, 2023 at 10:36 AM RuiRui Yang wrote:
> >
> > On Mon, 27 Nov 2023 at 09:53, RuiRui Yang wrote:
> > >
> > > On Sat, 25 Nov 2023 at 14:54, WANG Rui 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:
> > > > pei_loongarch_load: kernel_entry: 013f1000
> > > > pei_loongarch_load: image_size: 01ca
> > > > pei_loongarch_load: text_offset:0020
> > > > pei_loongarch_load: phys_offset:
> > > > pei_loongarch_load: PE format: yes
> > > > loongarch_load_other_segments:333: command_line: kexec
> > > > console=ttyS0,115200
> > > > kexec_load: entry = 0x13f1000 flags = 0x102
> > > > nr_segments = 2
> > > > segment[0].buf = 0x7fffeea38010
> > > > segment[0].bufsz = 0x1b55200
> > > > segment[0].mem = (nil)
> > > > segment[0].memsz = 0x1ca
> > > > segment[1].buf = 0x570940b0
> > > > segment[1].bufsz = 0x200
> > > > segment[1].mem = 0x1ca
> > > > 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: 0020
> > > > pei_loongarch_load: kernel_entry: 013f1000
> > > > pei_loongarch_load: image_size: 01ca
> > > > pei_loongarch_load: text_offset:0020
> > > > pei_loongarch_load: phys_offset:
> > > > pei_loongarch_load: PE format: yes
> > > > loongarch_load_other_segments:339: command_line: kexec
> > > > console=ttyS0,115200
> > > > kexec_load: entry = 0x13f1000 flags = 0x102
> > > > nr_segments = 2
> > > > segment[0].buf = 0x72028010
> > > > segment[0].bufsz = 0x1b55200
> > > > segment[0].mem = 0x20
> > > > segment[0].memsz = 0x1ca
> > > > segment[1].buf = 0x57498098
> > > > segment[1].bufsz = 0x200
> > > > segment[1].mem = 0x1ea
> > > > segment[1].memsz = 0x4000
> > > >
> > > > Signed-off-by: WANG Rui
> > > > ---
> > > >
> > > > 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 ,
> > 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
Re: [PATCH v2] LoongArch: Load vmlinux.efi to the link address
Hello Simon,
Could you apply this patch (v2) instead of patch (v1) [1] ?
Thanks!
[1] https://lore.kernel.org/kexec/20231124154658.114579-1-wang...@loongson.cn/
On Sat, Nov 25, 2023 at 2:52 PM WANG Rui 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:
> pei_loongarch_load: kernel_entry: 013f1000
> pei_loongarch_load: image_size: 01ca
> pei_loongarch_load: text_offset:0020
> pei_loongarch_load: phys_offset:
> pei_loongarch_load: PE format: yes
> loongarch_load_other_segments:333: command_line: kexec console=ttyS0,115200
> kexec_load: entry = 0x13f1000 flags = 0x102
> nr_segments = 2
> segment[0].buf = 0x7fffeea38010
> segment[0].bufsz = 0x1b55200
> segment[0].mem = (nil)
> segment[0].memsz = 0x1ca
> segment[1].buf = 0x570940b0
> segment[1].bufsz = 0x200
> segment[1].mem = 0x1ca
> 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: 0020
> pei_loongarch_load: kernel_entry: 013f1000
> pei_loongarch_load: image_size: 01ca
> pei_loongarch_load: text_offset:0020
> pei_loongarch_load: phys_offset:
> pei_loongarch_load: PE format: yes
> loongarch_load_other_segments:339: command_line: kexec console=ttyS0,115200
> kexec_load: entry = 0x13f1000 flags = 0x102
> nr_segments = 2
> segment[0].buf = 0x72028010
> segment[0].bufsz = 0x1b55200
> segment[0].mem = 0x20
> segment[0].memsz = 0x1ca
> segment[1].buf = 0x57498098
> segment[1].bufsz = 0x200
> segment[1].mem = 0x1ea
> segment[1].memsz = 0x4000
>
> Signed-off-by: WANG Rui
> ---
>
> 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
Hi,
On Mon, Nov 27, 2023 at 10:36 AM RuiRui Yang wrote:
>
> On Mon, 27 Nov 2023 at 09:53, RuiRui Yang wrote:
> >
> > On Sat, 25 Nov 2023 at 14:54, WANG Rui 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:
> > > pei_loongarch_load: kernel_entry: 013f1000
> > > pei_loongarch_load: image_size: 01ca
> > > pei_loongarch_load: text_offset:0020
> > > pei_loongarch_load: phys_offset:
> > > pei_loongarch_load: PE format: yes
> > > loongarch_load_other_segments:333: command_line: kexec
> > > console=ttyS0,115200
> > > kexec_load: entry = 0x13f1000 flags = 0x102
> > > nr_segments = 2
> > > segment[0].buf = 0x7fffeea38010
> > > segment[0].bufsz = 0x1b55200
> > > segment[0].mem = (nil)
> > > segment[0].memsz = 0x1ca
> > > segment[1].buf = 0x570940b0
> > > segment[1].bufsz = 0x200
> > > segment[1].mem = 0x1ca
> > > 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: 0020
> > > pei_loongarch_load: kernel_entry: 013f1000
> > > pei_loongarch_load: image_size: 01ca
> > > pei_loongarch_load: text_offset:0020
> > > pei_loongarch_load: phys_offset:
> > > pei_loongarch_load: PE format: yes
> > > loongarch_load_other_segments:339: command_line: kexec
> > > console=ttyS0,115200
> > > kexec_load: entry = 0x13f1000 flags = 0x102
> > > nr_segments = 2
> > > segment[0].buf = 0x72028010
> > > segment[0].bufsz = 0x1b55200
> > > segment[0].mem = 0x20
> > > segment[0].memsz = 0x1ca
> > > segment[1].buf = 0x57498098
> > > segment[1].bufsz = 0x200
> > > segment[1].mem = 0x1ea
> > > segment[1].memsz = 0x4000
> > >
> > > Signed-off-by: WANG Rui
> > > ---
> > >
> > > 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 ,
> 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
> >
Re: [PATCH v2] LoongArch: Load vmlinux.efi to the link address
On Mon, 27 Nov 2023 at 09:53, RuiRui Yang wrote:
>
> On Sat, 25 Nov 2023 at 14:54, WANG Rui 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:
> > pei_loongarch_load: kernel_entry: 013f1000
> > pei_loongarch_load: image_size: 01ca
> > pei_loongarch_load: text_offset:0020
> > pei_loongarch_load: phys_offset:
> > pei_loongarch_load: PE format: yes
> > loongarch_load_other_segments:333: command_line: kexec
> > console=ttyS0,115200
> > kexec_load: entry = 0x13f1000 flags = 0x102
> > nr_segments = 2
> > segment[0].buf = 0x7fffeea38010
> > segment[0].bufsz = 0x1b55200
> > segment[0].mem = (nil)
> > segment[0].memsz = 0x1ca
> > segment[1].buf = 0x570940b0
> > segment[1].bufsz = 0x200
> > segment[1].mem = 0x1ca
> > 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: 0020
> > pei_loongarch_load: kernel_entry: 013f1000
> > pei_loongarch_load: image_size: 01ca
> > pei_loongarch_load: text_offset:0020
> > pei_loongarch_load: phys_offset:
> > pei_loongarch_load: PE format: yes
> > loongarch_load_other_segments:339: command_line: kexec
> > console=ttyS0,115200
> > kexec_load: entry = 0x13f1000 flags = 0x102
> > nr_segments = 2
> > segment[0].buf = 0x72028010
> > segment[0].bufsz = 0x1b55200
> > segment[0].mem = 0x20
> > segment[0].memsz = 0x1ca
> > segment[1].buf = 0x57498098
> > segment[1].bufsz = 0x200
> > segment[1].mem = 0x1ea
> > segment[1].memsz = 0x4000
> >
> > Signed-off-by: WANG Rui
> > ---
> >
> > 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 ,
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, , 0);
>
> - /* Reserve the first 2MB */
> - memblock_reserve(PHYS_OFFSET, 0x20);
> + /* Mark the first 2MB as nomap */
> + memblock_mark_nomap(PHYS_OFFSET, 0x20);
>
> /* Reserve the kernel text/data/bss */
> memblock_reserve(__pa_symbol(&_text),
>
>
> > --
> > 2.42.0
> >
> >
> > ___
> > kexec mailing
Re: [PATCH v2] LoongArch: Load vmlinux.efi to the link address
On Sat, 25 Nov 2023 at 14:54, WANG Rui 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:
> pei_loongarch_load: kernel_entry: 013f1000
> pei_loongarch_load: image_size: 01ca
> pei_loongarch_load: text_offset:0020
> pei_loongarch_load: phys_offset:
> pei_loongarch_load: PE format: yes
> loongarch_load_other_segments:333: command_line: kexec console=ttyS0,115200
> kexec_load: entry = 0x13f1000 flags = 0x102
> nr_segments = 2
> segment[0].buf = 0x7fffeea38010
> segment[0].bufsz = 0x1b55200
> segment[0].mem = (nil)
> segment[0].memsz = 0x1ca
> segment[1].buf = 0x570940b0
> segment[1].bufsz = 0x200
> segment[1].mem = 0x1ca
> 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: 0020
> pei_loongarch_load: kernel_entry: 013f1000
> pei_loongarch_load: image_size: 01ca
> pei_loongarch_load: text_offset:0020
> pei_loongarch_load: phys_offset:
> pei_loongarch_load: PE format: yes
> loongarch_load_other_segments:339: command_line: kexec console=ttyS0,115200
> kexec_load: entry = 0x13f1000 flags = 0x102
> nr_segments = 2
> segment[0].buf = 0x72028010
> segment[0].bufsz = 0x1b55200
> segment[0].mem = 0x20
> segment[0].memsz = 0x1ca
> segment[1].buf = 0x57498098
> segment[1].bufsz = 0x200
> segment[1].mem = 0x1ea
> segment[1].memsz = 0x4000
>
> Signed-off-by: WANG Rui
> ---
>
> 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, , 0);
- /* Reserve the first 2MB */
- memblock_reserve(PHYS_OFFSET, 0x20);
+ /* Mark the first 2MB as nomap */
+ memblock_mark_nomap(PHYS_OFFSET, 0x20);
/* 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
Reviewed-by: Huacai Chen
On Sat, Nov 25, 2023 at 2:53 PM WANG Rui 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:
> pei_loongarch_load: kernel_entry: 013f1000
> pei_loongarch_load: image_size: 01ca
> pei_loongarch_load: text_offset:0020
> pei_loongarch_load: phys_offset:
> pei_loongarch_load: PE format: yes
> loongarch_load_other_segments:333: command_line: kexec console=ttyS0,115200
> kexec_load: entry = 0x13f1000 flags = 0x102
> nr_segments = 2
> segment[0].buf = 0x7fffeea38010
> segment[0].bufsz = 0x1b55200
> segment[0].mem = (nil)
> segment[0].memsz = 0x1ca
> segment[1].buf = 0x570940b0
> segment[1].bufsz = 0x200
> segment[1].mem = 0x1ca
> 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: 0020
> pei_loongarch_load: kernel_entry: 013f1000
> pei_loongarch_load: image_size: 01ca
> pei_loongarch_load: text_offset:0020
> pei_loongarch_load: phys_offset:
> pei_loongarch_load: PE format: yes
> loongarch_load_other_segments:339: command_line: kexec console=ttyS0,115200
> kexec_load: entry = 0x13f1000 flags = 0x102
> nr_segments = 2
> segment[0].buf = 0x72028010
> segment[0].bufsz = 0x1b55200
> segment[0].mem = 0x20
> segment[0].memsz = 0x1ca
> segment[1].buf = 0x57498098
> segment[1].bufsz = 0x200
> segment[1].mem = 0x1ea
> segment[1].memsz = 0x4000
>
> Signed-off-by: WANG Rui
> ---
>
> 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
[PATCH v2] LoongArch: Load vmlinux.efi to the link address
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:
pei_loongarch_load: kernel_entry: 013f1000
pei_loongarch_load: image_size: 01ca
pei_loongarch_load: text_offset:0020
pei_loongarch_load: phys_offset:
pei_loongarch_load: PE format: yes
loongarch_load_other_segments:333: command_line: kexec console=ttyS0,115200
kexec_load: entry = 0x13f1000 flags = 0x102
nr_segments = 2
segment[0].buf = 0x7fffeea38010
segment[0].bufsz = 0x1b55200
segment[0].mem = (nil)
segment[0].memsz = 0x1ca
segment[1].buf = 0x570940b0
segment[1].bufsz = 0x200
segment[1].mem = 0x1ca
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: 0020
pei_loongarch_load: kernel_entry: 013f1000
pei_loongarch_load: image_size: 01ca
pei_loongarch_load: text_offset:0020
pei_loongarch_load: phys_offset:
pei_loongarch_load: PE format: yes
loongarch_load_other_segments:339: command_line: kexec console=ttyS0,115200
kexec_load: entry = 0x13f1000 flags = 0x102
nr_segments = 2
segment[0].buf = 0x72028010
segment[0].bufsz = 0x1b55200
segment[0].mem = 0x20
segment[0].memsz = 0x1ca
segment[1].buf = 0x57498098
segment[1].bufsz = 0x200
segment[1].mem = 0x1ea
segment[1].memsz = 0x4000
Signed-off-by: WANG Rui
---
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
