Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
On 04/04/19 at 02:22pm, Borislav Petkov wrote: > On Thu, Apr 04, 2019 at 03:41:02PM +0800, Dave Young wrote: > > It is hard to find 32bit efi hardware, I can confirm all the laptop I > > have are 64bit efi. > > You can use 32-bit OVMF with qemu, like in the link Chao gave a couple > of mails earlier. Since my case is not 32bit related, let me continue to get what happens on 64bit laptops first. 32bit test can be done after that. Thanks Dave ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
On Thu, Apr 04, 2019 at 03:41:02PM +0800, Dave Young wrote: > It is hard to find 32bit efi hardware, I can confirm all the laptop I > have are 64bit efi. You can use 32-bit OVMF with qemu, like in the link Chao gave a couple of mails earlier. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
On Thu, Apr 04, 2019 at 03:41:02PM +0800, Dave Young wrote:
>Hi Chao,
>On 04/04/19 at 03:20pm, Chao Fan wrote:
>> On Thu, Apr 04, 2019 at 02:41:30PM +0800, Dave Young wrote:
>> >On 04/04/19 at 11:22am, Dave Young wrote:
>> >> On 04/04/19 at 11:10am, Baoquan He wrote:
>> >> > On 04/04/19 at 11:00am, Baoquan He wrote:
>> >> > > On 04/04/19 at 10:52am, Dave Young wrote:
>> >> > > > On 04/04/19 at 01:23am, Junichi Nomura wrote:
>> >> > + /* Save RSDP address for later use. */
>> >> > + boot_params->acpi_rsdp_addr = get_rsdp_addr();
>> >> > +
>> >> > + error("Hang kernel for kexec debugging");
>> >> >
>> >> > Sorry, here I means calling error() to hang kernel after calling
>> >> > get_rsdp_addr().
>> >>
>> >> Thanks, it did not hang, it always reset to firmware/grub boot menu.
>> >> I'm pretty sure now the bug exists in get_rsdp_addr().
>> >
>> >static acpi_physical_address kexec_get_rsdp_addr(void)
>> >{
>> >...
>> >/* Get systab from boot params. */
>> >systab = (efi_system_table_64_t *) (ei->efi_systab |
>> > ((__u64)ei->efi_systab_hi << 32));
>> >if (!systab)
>> > error("EFI system table not found in kexec boot_params.");
>> >
>> >...
>> > -> add error("hang me") here will have a hang
>> >...
>> >return __efi_get_rsdp_addr((unsigned long)esd->tables,
>> > systab->nr_tables, true);
>> >
>>
>> I have an idea, but not sure whether is a problem.
>> In code of Nomura:
>>
>> #if defined(CONFIG_EFI) && defined(CONFIG_X86_64)
>> [...]
>> if (strncmp(sig, EFI64_LOADER_SIGNATURE, 4)) {
>> debug_putstr("Wrong kexec EFI loader signature.\n");
>> return 0;
>> }
>>
>> /* Get systab from boot params. */
>> systab = (efi_system_table_64_t *) (ei->efi_systab |
>> ((__u64)ei->efi_systab_hi << 32));
>> [...]
>> #endif
>>
>> After review agian, I wonder what will happen if 32bit-efi boot 64bit
>> OS.
>
>It is hard to find 32bit efi hardware, I can confirm all the laptop I
>have are 64bit efi.
>
>In case 32bit efi EFI64_LOADER_SIGNATURE checking will be false.
Yes, just when reviewing code, I notice this problem.
Thanks,
Chao Fan
>
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
Hi Chao,
On 04/04/19 at 03:20pm, Chao Fan wrote:
> On Thu, Apr 04, 2019 at 02:41:30PM +0800, Dave Young wrote:
> >On 04/04/19 at 11:22am, Dave Young wrote:
> >> On 04/04/19 at 11:10am, Baoquan He wrote:
> >> > On 04/04/19 at 11:00am, Baoquan He wrote:
> >> > > On 04/04/19 at 10:52am, Dave Young wrote:
> >> > > > On 04/04/19 at 01:23am, Junichi Nomura wrote:
> >> > + /* Save RSDP address for later use. */
> >> > + boot_params->acpi_rsdp_addr = get_rsdp_addr();
> >> > +
> >> > + error("Hang kernel for kexec debugging");
> >> >
> >> > Sorry, here I means calling error() to hang kernel after calling
> >> > get_rsdp_addr().
> >>
> >> Thanks, it did not hang, it always reset to firmware/grub boot menu.
> >> I'm pretty sure now the bug exists in get_rsdp_addr().
> >
> >static acpi_physical_address kexec_get_rsdp_addr(void)
> >{
> >...
> >/* Get systab from boot params. */
> >systab = (efi_system_table_64_t *) (ei->efi_systab |
> > ((__u64)ei->efi_systab_hi << 32));
> >if (!systab)
> > error("EFI system table not found in kexec boot_params.");
> >
> >...
> > -> add error("hang me") here will have a hang
> >...
> >return __efi_get_rsdp_addr((unsigned long)esd->tables,
> > systab->nr_tables, true);
> >
>
> I have an idea, but not sure whether is a problem.
> In code of Nomura:
>
> #if defined(CONFIG_EFI) && defined(CONFIG_X86_64)
> [...]
> if (strncmp(sig, EFI64_LOADER_SIGNATURE, 4)) {
> debug_putstr("Wrong kexec EFI loader signature.\n");
> return 0;
> }
>
> /* Get systab from boot params. */
> systab = (efi_system_table_64_t *) (ei->efi_systab |
> ((__u64)ei->efi_systab_hi << 32));
> [...]
> #endif
>
> After review agian, I wonder what will happen if 32bit-efi boot 64bit
> OS.
It is hard to find 32bit efi hardware, I can confirm all the laptop I
have are 64bit efi.
In case 32bit efi EFI64_LOADER_SIGNATURE checking will be false.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
On Thu, Apr 04, 2019 at 02:41:30PM +0800, Dave Young wrote:
>On 04/04/19 at 11:22am, Dave Young wrote:
>> On 04/04/19 at 11:10am, Baoquan He wrote:
>> > On 04/04/19 at 11:00am, Baoquan He wrote:
>> > > On 04/04/19 at 10:52am, Dave Young wrote:
>> > > > On 04/04/19 at 01:23am, Junichi Nomura wrote:
>> > + /* Save RSDP address for later use. */
>> > + boot_params->acpi_rsdp_addr = get_rsdp_addr();
>> > +
>> > + error("Hang kernel for kexec debugging");
>> >
>> > Sorry, here I means calling error() to hang kernel after calling
>> > get_rsdp_addr().
>>
>> Thanks, it did not hang, it always reset to firmware/grub boot menu.
>> I'm pretty sure now the bug exists in get_rsdp_addr().
>
>static acpi_physical_address kexec_get_rsdp_addr(void)
>{
>...
>/* Get systab from boot params. */
>systab = (efi_system_table_64_t *) (ei->efi_systab |
> ((__u64)ei->efi_systab_hi << 32));
>if (!systab)
> error("EFI system table not found in kexec boot_params.");
>
>...
> -> add error("hang me") here will have a hang
>...
>return __efi_get_rsdp_addr((unsigned long)esd->tables,
> systab->nr_tables, true);
>
I have an idea, but not sure whether is a problem.
In code of Nomura:
#if defined(CONFIG_EFI) && defined(CONFIG_X86_64)
[...]
if (strncmp(sig, EFI64_LOADER_SIGNATURE, 4)) {
debug_putstr("Wrong kexec EFI loader signature.\n");
return 0;
}
/* Get systab from boot params. */
systab = (efi_system_table_64_t *) (ei->efi_systab |
((__u64)ei->efi_systab_hi << 32));
[...]
#endif
After review agian, I wonder what will happen if 32bit-efi boot 64bit
OS.
Ever meet a problem:
https://lkml.org/lkml/2019/2/8/845
It's a efi32 bootloader to boot a 64bit OS, then a problem happened.
Thanks,
Chao Fan
>But add error("hang me") in __efi_get_rsdp_addr it did not hang.
>
>It seems reference the systab pointer cause a system reset.
>
>A question is does the identity mapping covered the memory address of
>systab?
>
>In my case it is 0xdad9ef18
>
>If the memory is mapped on demand, then there will be problems, it
>should cover setup_data and efi table space.
>
>Thanks
>Dave
>
>
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
On 04/04/19 at 11:22am, Dave Young wrote:
> On 04/04/19 at 11:10am, Baoquan He wrote:
> > On 04/04/19 at 11:00am, Baoquan He wrote:
> > > On 04/04/19 at 10:52am, Dave Young wrote:
> > > > On 04/04/19 at 01:23am, Junichi Nomura wrote:
> > > > > Hi Dave and Chao,
> > > > >
> > > > > On 4/3/19 6:02 PM, Chao Fan wrote:
> > > > > > On Wed, Apr 03, 2019 at 04:23:06PM +0800, Chao Fan wrote:
> > > > > >> On Wed, Apr 03, 2019 at 04:09:16PM +0800, Dave Young wrote:
> > > > > >>> Fix 3. need more debugging, have you or Junichi run tests on
> > > > > >>> more real
> > > > > >>> hardware, maybe it is easier to reproduce on real hardware, I'm
> > > > > >>> glad to
> > > > > >>> help to try test patch or provide any help.
> > > > > >>
> > > > > >> I am still testing in real hardware.
> > > > > >
> > > > > > Hi Dave,
> > > > > >
> > > > > > I find a Fujitsu Desktop PC to test it.
> > > > > > Without this PATCH, it failed to kexec and kdump.
> > > > > > With this PATCH, it succeed to kexec.
> > > > > > But failed to kdump. From the log, I think it didn't jump to the
> > > > > > second
> > > > > > kernel, just reboot after panic. I have not figured out what's the
> > > > > > problem, but it seems not caused by this PATCH.
> > > > > > So I still think this PATCH works for the Fujitsu Desktop PC.
> > > > > >
> > > > > > As for your issue, I think there may be some problems related to
> > > > > > specified
> > > > > > hardware. Are you using a Lenovo laptop?
> > > > > >
> > > > > > And I am not sure how Nomura tested it.
> > > > >
> > > > > I've tested 3 different models of EFI-booted baremetal servers with
> > > > > both
> > > > > normal kexec and panic kexec. So far as I've tried Linus's v5.1-rc3,
> > > > > the problem always reproduced without the patch and disappears with
> > > > > the patch.
> > > >
> > > > Hmm, both of my two laptops (Thinkpad T480s and T420) failed to boot
> > > > with kexec.
> > > >
> > > > I will see if I can find something, but it may need more time because
> > > > early console does not work especially after kexec.
> > >
> > > Dave, can you try below patch to print debugging message and hang kernel
> > > to check the outputting? The hang is necessary, otherwise later printk
> > > printking will overwrite it.
> > >
> > > diff --git a/arch/x86/boot/compressed/misc.c
> > > b/arch/x86/boot/compressed/misc.c
> > > index c0d6c560df69..68119547c4aa 100644
> > > --- a/arch/x86/boot/compressed/misc.c
> > > +++ b/arch/x86/boot/compressed/misc.c
> > > @@ -351,9 +351,6 @@ asmlinkage __visible void *extract_kernel(void
> > > *rmode, memptr heap,
> > > /* Clear flags intended for solely in-kernel use. */
> > > boot_params->hdr.loadflags &= ~KASLR_FLAG;
> > >
> > > - /* Save RSDP address for later use. */
> > > - boot_params->acpi_rsdp_addr = get_rsdp_addr();
> > > -
> > > sanitize_boot_params(boot_params);
> > >
> > > if (boot_params->screen_info.orig_video_mode == 7) {
> > > @@ -370,6 +367,10 @@ asmlinkage __visible void *extract_kernel(void
> > > *rmode, memptr heap,
> > > console_init();
> > > debug_putstr("early console in extract_kernel\n");
> > >
> > + /* Save RSDP address for later use. */
> > + boot_params->acpi_rsdp_addr = get_rsdp_addr();
> > +
> > + error("Hang kernel for kexec debugging");
> >
> > Sorry, here I means calling error() to hang kernel after calling
> > get_rsdp_addr().
>
> Thanks, it did not hang, it always reset to firmware/grub boot menu.
> I'm pretty sure now the bug exists in get_rsdp_addr().
static acpi_physical_address kexec_get_rsdp_addr(void)
{
...
/* Get systab from boot params. */
systab = (efi_system_table_64_t *) (ei->efi_systab |
((__u64)ei->efi_systab_hi << 32));
if (!systab)
error("EFI system table not found in kexec boot_params.");
...
-> add error("hang me") here will have a hang
...
return __efi_get_rsdp_addr((unsigned long)esd->tables,
systab->nr_tables, true);
But add error("hang me") in __efi_get_rsdp_addr it did not hang.
It seems reference the systab pointer cause a system reset.
A question is does the identity mapping covered the memory address of
systab?
In my case it is 0xdad9ef18
If the memory is mapped on demand, then there will be problems, it
should cover setup_data and efi table space.
Thanks
Dave
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
On 04/04/19 at 11:10am, Baoquan He wrote:
> On 04/04/19 at 11:00am, Baoquan He wrote:
> > On 04/04/19 at 10:52am, Dave Young wrote:
> > > On 04/04/19 at 01:23am, Junichi Nomura wrote:
> > > > Hi Dave and Chao,
> > > >
> > > > On 4/3/19 6:02 PM, Chao Fan wrote:
> > > > > On Wed, Apr 03, 2019 at 04:23:06PM +0800, Chao Fan wrote:
> > > > >> On Wed, Apr 03, 2019 at 04:09:16PM +0800, Dave Young wrote:
> > > > >>> Fix 3. need more debugging, have you or Junichi run tests on more
> > > > >>> real
> > > > >>> hardware, maybe it is easier to reproduce on real hardware, I'm
> > > > >>> glad to
> > > > >>> help to try test patch or provide any help.
> > > > >>
> > > > >> I am still testing in real hardware.
> > > > >
> > > > > Hi Dave,
> > > > >
> > > > > I find a Fujitsu Desktop PC to test it.
> > > > > Without this PATCH, it failed to kexec and kdump.
> > > > > With this PATCH, it succeed to kexec.
> > > > > But failed to kdump. From the log, I think it didn't jump to the
> > > > > second
> > > > > kernel, just reboot after panic. I have not figured out what's the
> > > > > problem, but it seems not caused by this PATCH.
> > > > > So I still think this PATCH works for the Fujitsu Desktop PC.
> > > > >
> > > > > As for your issue, I think there may be some problems related to
> > > > > specified
> > > > > hardware. Are you using a Lenovo laptop?
> > > > >
> > > > > And I am not sure how Nomura tested it.
> > > >
> > > > I've tested 3 different models of EFI-booted baremetal servers with both
> > > > normal kexec and panic kexec. So far as I've tried Linus's v5.1-rc3,
> > > > the problem always reproduced without the patch and disappears with the
> > > > patch.
> > >
> > > Hmm, both of my two laptops (Thinkpad T480s and T420) failed to boot with
> > > kexec.
> > >
> > > I will see if I can find something, but it may need more time because
> > > early console does not work especially after kexec.
> >
> > Dave, can you try below patch to print debugging message and hang kernel
> > to check the outputting? The hang is necessary, otherwise later printk
> > printking will overwrite it.
> >
> > diff --git a/arch/x86/boot/compressed/misc.c
> > b/arch/x86/boot/compressed/misc.c
> > index c0d6c560df69..68119547c4aa 100644
> > --- a/arch/x86/boot/compressed/misc.c
> > +++ b/arch/x86/boot/compressed/misc.c
> > @@ -351,9 +351,6 @@ asmlinkage __visible void *extract_kernel(void *rmode,
> > memptr heap,
> > /* Clear flags intended for solely in-kernel use. */
> > boot_params->hdr.loadflags &= ~KASLR_FLAG;
> >
> > - /* Save RSDP address for later use. */
> > - boot_params->acpi_rsdp_addr = get_rsdp_addr();
> > -
> > sanitize_boot_params(boot_params);
> >
> > if (boot_params->screen_info.orig_video_mode == 7) {
> > @@ -370,6 +367,10 @@ asmlinkage __visible void *extract_kernel(void *rmode,
> > memptr heap,
> > console_init();
> > debug_putstr("early console in extract_kernel\n");
> >
> +/* Save RSDP address for later use. */
> +boot_params->acpi_rsdp_addr = get_rsdp_addr();
> +
> +error("Hang kernel for kexec debugging");
>
> Sorry, here I means calling error() to hang kernel after calling
> get_rsdp_addr().
Thanks, it did not hang, it always reset to firmware/grub boot menu.
I'm pretty sure now the bug exists in get_rsdp_addr().
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
On 04/04/19 at 11:00am, Baoquan He wrote:
> On 04/04/19 at 10:52am, Dave Young wrote:
> > On 04/04/19 at 01:23am, Junichi Nomura wrote:
> > > Hi Dave and Chao,
> > >
> > > On 4/3/19 6:02 PM, Chao Fan wrote:
> > > > On Wed, Apr 03, 2019 at 04:23:06PM +0800, Chao Fan wrote:
> > > >> On Wed, Apr 03, 2019 at 04:09:16PM +0800, Dave Young wrote:
> > > >>> Fix 3. need more debugging, have you or Junichi run tests on more
> > > >>> real
> > > >>> hardware, maybe it is easier to reproduce on real hardware, I'm glad
> > > >>> to
> > > >>> help to try test patch or provide any help.
> > > >>
> > > >> I am still testing in real hardware.
> > > >
> > > > Hi Dave,
> > > >
> > > > I find a Fujitsu Desktop PC to test it.
> > > > Without this PATCH, it failed to kexec and kdump.
> > > > With this PATCH, it succeed to kexec.
> > > > But failed to kdump. From the log, I think it didn't jump to the second
> > > > kernel, just reboot after panic. I have not figured out what's the
> > > > problem, but it seems not caused by this PATCH.
> > > > So I still think this PATCH works for the Fujitsu Desktop PC.
> > > >
> > > > As for your issue, I think there may be some problems related to
> > > > specified
> > > > hardware. Are you using a Lenovo laptop?
> > > >
> > > > And I am not sure how Nomura tested it.
> > >
> > > I've tested 3 different models of EFI-booted baremetal servers with both
> > > normal kexec and panic kexec. So far as I've tried Linus's v5.1-rc3,
> > > the problem always reproduced without the patch and disappears with the
> > > patch.
> >
> > Hmm, both of my two laptops (Thinkpad T480s and T420) failed to boot with
> > kexec.
> >
> > I will see if I can find something, but it may need more time because
> > early console does not work especially after kexec.
>
> Dave, can you try below patch to print debugging message and hang kernel
> to check the outputting? The hang is necessary, otherwise later printk
> printking will overwrite it.
>
> diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
> index c0d6c560df69..68119547c4aa 100644
> --- a/arch/x86/boot/compressed/misc.c
> +++ b/arch/x86/boot/compressed/misc.c
> @@ -351,9 +351,6 @@ asmlinkage __visible void *extract_kernel(void *rmode,
> memptr heap,
> /* Clear flags intended for solely in-kernel use. */
> boot_params->hdr.loadflags &= ~KASLR_FLAG;
>
> - /* Save RSDP address for later use. */
> - boot_params->acpi_rsdp_addr = get_rsdp_addr();
> -
> sanitize_boot_params(boot_params);
>
> if (boot_params->screen_info.orig_video_mode == 7) {
> @@ -370,6 +367,10 @@ asmlinkage __visible void *extract_kernel(void *rmode,
> memptr heap,
> console_init();
> debug_putstr("early console in extract_kernel\n");
>
+ /* Save RSDP address for later use. */
+ boot_params->acpi_rsdp_addr = get_rsdp_addr();
+
+ error("Hang kernel for kexec debugging");
Sorry, here I means calling error() to hang kernel after calling
get_rsdp_addr().
> free_mem_ptr = heap;/* Heap */
> free_mem_end_ptr = heap + BOOT_HEAP_SIZE;
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
On 04/04/19 at 10:52am, Dave Young wrote:
> On 04/04/19 at 01:23am, Junichi Nomura wrote:
> > Hi Dave and Chao,
> >
> > On 4/3/19 6:02 PM, Chao Fan wrote:
> > > On Wed, Apr 03, 2019 at 04:23:06PM +0800, Chao Fan wrote:
> > >> On Wed, Apr 03, 2019 at 04:09:16PM +0800, Dave Young wrote:
> > >>> Fix 3. need more debugging, have you or Junichi run tests on more real
> > >>> hardware, maybe it is easier to reproduce on real hardware, I'm glad to
> > >>> help to try test patch or provide any help.
> > >>
> > >> I am still testing in real hardware.
> > >
> > > Hi Dave,
> > >
> > > I find a Fujitsu Desktop PC to test it.
> > > Without this PATCH, it failed to kexec and kdump.
> > > With this PATCH, it succeed to kexec.
> > > But failed to kdump. From the log, I think it didn't jump to the second
> > > kernel, just reboot after panic. I have not figured out what's the
> > > problem, but it seems not caused by this PATCH.
> > > So I still think this PATCH works for the Fujitsu Desktop PC.
> > >
> > > As for your issue, I think there may be some problems related to specified
> > > hardware. Are you using a Lenovo laptop?
> > >
> > > And I am not sure how Nomura tested it.
> >
> > I've tested 3 different models of EFI-booted baremetal servers with both
> > normal kexec and panic kexec. So far as I've tried Linus's v5.1-rc3,
> > the problem always reproduced without the patch and disappears with the
> > patch.
>
> Hmm, both of my two laptops (Thinkpad T480s and T420) failed to boot with
> kexec.
>
> I will see if I can find something, but it may need more time because
> early console does not work especially after kexec.
Dave, can you try below patch to print debugging message and hang kernel
to check the outputting? The hang is necessary, otherwise later printk
printking will overwrite it.
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index c0d6c560df69..68119547c4aa 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -351,9 +351,6 @@ asmlinkage __visible void *extract_kernel(void *rmode,
memptr heap,
/* Clear flags intended for solely in-kernel use. */
boot_params->hdr.loadflags &= ~KASLR_FLAG;
- /* Save RSDP address for later use. */
- boot_params->acpi_rsdp_addr = get_rsdp_addr();
-
sanitize_boot_params(boot_params);
if (boot_params->screen_info.orig_video_mode == 7) {
@@ -370,6 +367,10 @@ asmlinkage __visible void *extract_kernel(void *rmode,
memptr heap,
console_init();
debug_putstr("early console in extract_kernel\n");
+ error("Hang kernel for kexec debugging");
+ /* Save RSDP address for later use. */
+ boot_params->acpi_rsdp_addr = get_rsdp_addr();
+
free_mem_ptr = heap;/* Heap */
free_mem_end_ptr = heap + BOOT_HEAP_SIZE;
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
On 04/04/19 at 01:23am, Junichi Nomura wrote: > Hi Dave and Chao, > > On 4/3/19 6:02 PM, Chao Fan wrote: > > On Wed, Apr 03, 2019 at 04:23:06PM +0800, Chao Fan wrote: > >> On Wed, Apr 03, 2019 at 04:09:16PM +0800, Dave Young wrote: > >>> Fix 3. need more debugging, have you or Junichi run tests on more real > >>> hardware, maybe it is easier to reproduce on real hardware, I'm glad to > >>> help to try test patch or provide any help. > >> > >> I am still testing in real hardware. > > > > Hi Dave, > > > > I find a Fujitsu Desktop PC to test it. > > Without this PATCH, it failed to kexec and kdump. > > With this PATCH, it succeed to kexec. > > But failed to kdump. From the log, I think it didn't jump to the second > > kernel, just reboot after panic. I have not figured out what's the > > problem, but it seems not caused by this PATCH. > > So I still think this PATCH works for the Fujitsu Desktop PC. > > > > As for your issue, I think there may be some problems related to specified > > hardware. Are you using a Lenovo laptop? > > > > And I am not sure how Nomura tested it. > > I've tested 3 different models of EFI-booted baremetal servers with both > normal kexec and panic kexec. So far as I've tried Linus's v5.1-rc3, > the problem always reproduced without the patch and disappears with the patch. Hmm, both of my two laptops (Thinkpad T480s and T420) failed to boot with kexec. I will see if I can find something, but it may need more time because early console does not work especially after kexec. Thanks Dave ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
Hi Dave and Chao, On 4/3/19 6:02 PM, Chao Fan wrote: > On Wed, Apr 03, 2019 at 04:23:06PM +0800, Chao Fan wrote: >> On Wed, Apr 03, 2019 at 04:09:16PM +0800, Dave Young wrote: >>> Fix 3. need more debugging, have you or Junichi run tests on more real >>> hardware, maybe it is easier to reproduce on real hardware, I'm glad to >>> help to try test patch or provide any help. >> >> I am still testing in real hardware. > > Hi Dave, > > I find a Fujitsu Desktop PC to test it. > Without this PATCH, it failed to kexec and kdump. > With this PATCH, it succeed to kexec. > But failed to kdump. From the log, I think it didn't jump to the second > kernel, just reboot after panic. I have not figured out what's the > problem, but it seems not caused by this PATCH. > So I still think this PATCH works for the Fujitsu Desktop PC. > > As for your issue, I think there may be some problems related to specified > hardware. Are you using a Lenovo laptop? > > And I am not sure how Nomura tested it. I've tested 3 different models of EFI-booted baremetal servers with both normal kexec and panic kexec. So far as I've tried Linus's v5.1-rc3, the problem always reproduced without the patch and disappears with the patch. -- Jun'ichi Nomura, NEC Corporation / NEC Solution Innovators, Ltd. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
On Wed, Apr 03, 2019 at 06:14:29PM +0200, Borislav Petkov wrote: >On Wed, Apr 03, 2019 at 04:26:34PM +0800, Dave Young wrote: >> Personally I would like to have a cmdline to bypass the early acpi code >> because early code is hard to debug, if we have something weird happens >> we can try to gate out these code, and then get some idea.. > >No, this early crap better work on all machines by default. > >Also, Chao, are you telling me that you've only tested in a VM? Or In VM, with all cases. In real machine, test boot and RSDP parsing, not hotremove memory. Thanks, Chao Fan >have you actually tested your code on an actual machine with memory >hotremove? > >-- >Regards/Gruss, >Boris. > >Good mailing practices for 400: avoid top-posting and trim the reply. > > ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
On Wed, Apr 03, 2019 at 04:26:34PM +0800, Dave Young wrote: > Personally I would like to have a cmdline to bypass the early acpi code > because early code is hard to debug, if we have something weird happens > we can try to gate out these code, and then get some idea.. No, this early crap better work on all machines by default. Also, Chao, are you telling me that you've only tested in a VM? Or have you actually tested your code on an actual machine with memory hotremove? -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
On Wed, Apr 03, 2019 at 05:02:11PM +0800, Chao Fan wrote:
>On Wed, Apr 03, 2019 at 04:23:06PM +0800, Chao Fan wrote:
>>On Wed, Apr 03, 2019 at 04:09:16PM +0800, Dave Young wrote:
>>>On 04/03/19 at 03:21pm, Chao Fan wrote:
On Wed, Apr 03, 2019 at 01:53:40PM +0800, Dave Young wrote:
>On 04/03/19 at 01:35pm, Chao Fan wrote:
>> On Tue, Apr 02, 2019 at 08:03:19PM +0800, Dave Young wrote:
>> >On 04/01/19 at 12:08am, Junichi Nomura wrote:
>[...]
>
>It is weird to me. Probably I need find out why I can not reproduce the
>bug this patch is addressing first.
Hmm, is your laptop booted from EFI or legacy BIOS?
>>>
>>>EFI booted.
>>>
>
>earlyprintk seems not working for me anymore, it is not easy to debug on
>laptop now.
Another computer can help print the console message.
I remeber you are good at debug on two computers.
>>>
>>>I used to use earlyprintk, but seems earlyprintk can not work so early.
>>>So I only can try to comment out code manually.
>>
>>Ah, I got it. If you want to use earlyprintk to print message of
>>get_rsdp_addr(), you should change some code.
>>Because get_rsdp_addr() is called before earlyprintk initialed.
>>
>>I am still testing, but in my debug stage, I change like this:
>>diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
>>index c0d6c560df69..dbbe8d9a5792 100644
>>--- a/arch/x86/boot/compressed/misc.c
>>+++ b/arch/x86/boot/compressed/misc.c
>>@@ -352,7 +352,6 @@ asmlinkage __visible void *extract_kernel(void *rmode,
>>memptr heap,
>>boot_params->hdr.loadflags &= ~KASLR_FLAG;
>>
>>/* Save RSDP address for later use. */
>>- boot_params->acpi_rsdp_addr = get_rsdp_addr();
>>
>>sanitize_boot_params(boot_params);
>>
>>@@ -368,6 +367,7 @@ asmlinkage __visible void *extract_kernel(void *rmode,
>>memptr heap,
>>cols = boot_params->screen_info.orig_video_cols;
>>
>>console_init();
>>+ boot_params->acpi_rsdp_addr = get_rsdp_addr();
>>debug_putstr("early console in extract_kernel\n");
>>
>>free_mem_ptr = heap;/* Heap */
>>
>>Call this function after console_init().
>>That will make earlyprintk works.
>>
>>>
>>>It seems to be still some bug in early acpi code because if I
>>>return 0 in get rsdp function it just works.
>>>
>>>This guess make sense to me for now:
>>>1. nokaslr does not work because it may only avoid randomization, but it
>>>does not avoid running the early acpi parsing code.
>>>
>>>2. kexec does not work without the patch we talked about, because I just
>>>reproduced Junichi reported bug, sometimes hang, or reset, it is
>>>understandable.
>>>
>>>3. kexec does not work with the patch, so there is still bugs in the
>>>code.
>>>
>>>So several things to do is:
>>>
>>>Fix 1. (separate issue), Baoquan or either of you may want to fix it :)
>>
>>For 1, I think it's not needed to fix. Since not only KASLR needs RSDP.
>>So nokaslr should not stop the acpi parsing code.
>>>
>>>Fix 3. need more debugging, have you or Junichi run tests on more real
>>>hardware, maybe it is easier to reproduce on real hardware, I'm glad to
>>>help to try test patch or provide any help.
>>
>>I am still testing in real hardware.
>
>Hi Dave,
>
>I find a Fujitsu Desktop PC to test it.
>Without this PATCH, it failed to kexec and kdump.
>With this PATCH, it succeed to kexec.
>But failed to kdump. From the log, I think it didn't jump to the second
>kernel, just reboot after panic. I have not figured out what's the
>problem, but it seems not caused by this PATCH.
I comment out this line:
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index c0d6c560df69..4d826abe659c 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -352,7 +352,7 @@ asmlinkage __visible void *extract_kernel(void *rmode,
memptr heap,
boot_params->hdr.loadflags &= ~KASLR_FLAG;
/* Save RSDP address for later use. */
- boot_params->acpi_rsdp_addr = get_rsdp_addr();
+ //boot_params->acpi_rsdp_addr = get_rsdp_addr();
sanitize_boot_params(boot_params);
Kdump also failed to jump to the second kernel and just hang.
So I think it's another issue. As for this PATCH, I think it works.
So for now, we only find your laptop will meet the problem, so maybe
you can debug for more information.
Thanks,
Chao Fan
>So I still think this PATCH works for the Fujitsu Desktop PC.
>
>As for your issue, I think there may be some problems related to specified
>hardware. Are you using a Lenovo laptop?
>
>And I am not sure how Nomura tested it.
>
>Thanks,
>Chao Fan
>
>>
>>Thanks,
>>Chao Fan
>>
>>>
>>>Thanks
>>>Dave
>>>
>>>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
On Wed, Apr 03, 2019 at 03:50:15PM +0800, b...@redhat.com wrote: >On 04/03/19 at 03:30pm, Chao Fan wrote: >> On Wed, Apr 03, 2019 at 02:39:11PM +0800, Dave Young wrote: >> >> Actually I got some different kexec test results. >> >> >> >> Yesterday, with my installed kernel (based on git head several weeks >> >> ago), kexec kernel panics. >> >> >> >> Then I tried latest mainline with git pull, everything works, (with or >> >> without the patch, and can not reproduce the bug this patch is fixing) >> >> >> >> Today, test again, kexec reboot hangs (with or without your patch), but >> >> kdump works always (with or without the patch) >> >> >> >> It is weird to me. Probably I need find out why I can not reproduce the >> >> bug this patch is addressing first. >> >> >> >> earlyprintk seems not working for me anymore, it is not easy to debug on >> >> laptop now. >> >> >> >> But the patch itself is clear, I think it should be good. There might be >> >> other things broken. >> > >> >Disable your immovable mem code then everything works for me. There >> >might be something wrong in the code. Also "nokaslr" does not help, it >> >should be another problem >> >> If "nokaslr" doesn't help, so I think >> >+ /*num_immovable_mem = count_immovable_mem_regions();*/ >> also doesn't help. I think the problem is from get_rsdp_addr(). > >Yes, seems get_rsdp_addr() has issue in this case. I am wondering if we >can adjust the postion of get_rsdp_addr() calling. If nokaslr is >specified, no need to get rsdp? I think no, RSDP parsing dosn't only work for KASLR. Thanks, Chao Fan > >> >> You test it in your laptop, I only tested in Qemu guest. >> I have no laptop avaliable, so I will look for a physical machine >> to test it. >> >> Thanks, >> Chao Fan >> >> > >> >diff --git a/arch/x86/boot/compressed/kaslr.c >> >b/arch/x86/boot/compressed/kaslr.c >> >index 2e53c056ba20..e760c9159662 100644 >> >--- a/arch/x86/boot/compressed/kaslr.c >> >+++ b/arch/x86/boot/compressed/kaslr.c >> >@@ -416,7 +416,7 @@ static void mem_avoid_init(unsigned long input, >> >unsigned long input_size, >> >handle_mem_options(); >> > >> >/* Enumerate the immovable memory regions */ >> >- num_immovable_mem = count_immovable_mem_regions(); >> >+ /*num_immovable_mem = count_immovable_mem_regions();*/ >> > >> > #ifdef CONFIG_X86_VERBOSE_BOOTUP >> >/* Make sure video RAM can be used. */ >> >diff --git a/arch/x86/boot/compressed/misc.c >> >b/arch/x86/boot/compressed/misc.c >> >index c0d6c560df69..1bc6f46d3aa7 100644 >> >--- a/arch/x86/boot/compressed/misc.c >> >+++ b/arch/x86/boot/compressed/misc.c >> >@@ -352,7 +352,7 @@ asmlinkage __visible void *extract_kernel(void *rmode, >> >memptr heap, >> >boot_params->hdr.loadflags &= ~KASLR_FLAG; >> > >> >/* Save RSDP address for later use. */ >> >- boot_params->acpi_rsdp_addr = get_rsdp_addr(); >> >+/* boot_params->acpi_rsdp_addr = get_rsdp_addr(); */ >> > >> >sanitize_boot_params(boot_params); >> > >> > >> > >> >> > > ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
On Wed, Apr 03, 2019 at 04:23:06PM +0800, Chao Fan wrote:
>On Wed, Apr 03, 2019 at 04:09:16PM +0800, Dave Young wrote:
>>On 04/03/19 at 03:21pm, Chao Fan wrote:
>>> On Wed, Apr 03, 2019 at 01:53:40PM +0800, Dave Young wrote:
>>> >On 04/03/19 at 01:35pm, Chao Fan wrote:
>>> >> On Tue, Apr 02, 2019 at 08:03:19PM +0800, Dave Young wrote:
>>> >> >On 04/01/19 at 12:08am, Junichi Nomura wrote:
[...]
>>> >
>>> >It is weird to me. Probably I need find out why I can not reproduce the
>>> >bug this patch is addressing first.
>>>
>>> Hmm, is your laptop booted from EFI or legacy BIOS?
>>
>>EFI booted.
>>
>>> >
>>> >earlyprintk seems not working for me anymore, it is not easy to debug on
>>> >laptop now.
>>>
>>> Another computer can help print the console message.
>>> I remeber you are good at debug on two computers.
>>
>>I used to use earlyprintk, but seems earlyprintk can not work so early.
>>So I only can try to comment out code manually.
>
>Ah, I got it. If you want to use earlyprintk to print message of
>get_rsdp_addr(), you should change some code.
>Because get_rsdp_addr() is called before earlyprintk initialed.
>
>I am still testing, but in my debug stage, I change like this:
>diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
>index c0d6c560df69..dbbe8d9a5792 100644
>--- a/arch/x86/boot/compressed/misc.c
>+++ b/arch/x86/boot/compressed/misc.c
>@@ -352,7 +352,6 @@ asmlinkage __visible void *extract_kernel(void *rmode,
>memptr heap,
>boot_params->hdr.loadflags &= ~KASLR_FLAG;
>
>/* Save RSDP address for later use. */
>- boot_params->acpi_rsdp_addr = get_rsdp_addr();
>
>sanitize_boot_params(boot_params);
>
>@@ -368,6 +367,7 @@ asmlinkage __visible void *extract_kernel(void *rmode,
>memptr heap,
>cols = boot_params->screen_info.orig_video_cols;
>
>console_init();
>+ boot_params->acpi_rsdp_addr = get_rsdp_addr();
>debug_putstr("early console in extract_kernel\n");
>
>free_mem_ptr = heap;/* Heap */
>
>Call this function after console_init().
>That will make earlyprintk works.
>
>>
>>It seems to be still some bug in early acpi code because if I
>>return 0 in get rsdp function it just works.
>>
>>This guess make sense to me for now:
>>1. nokaslr does not work because it may only avoid randomization, but it
>>does not avoid running the early acpi parsing code.
>>
>>2. kexec does not work without the patch we talked about, because I just
>>reproduced Junichi reported bug, sometimes hang, or reset, it is
>>understandable.
>>
>>3. kexec does not work with the patch, so there is still bugs in the
>>code.
>>
>>So several things to do is:
>>
>>Fix 1. (separate issue), Baoquan or either of you may want to fix it :)
>
>For 1, I think it's not needed to fix. Since not only KASLR needs RSDP.
>So nokaslr should not stop the acpi parsing code.
>>
>>Fix 3. need more debugging, have you or Junichi run tests on more real
>>hardware, maybe it is easier to reproduce on real hardware, I'm glad to
>>help to try test patch or provide any help.
>
>I am still testing in real hardware.
Hi Dave,
I find a Fujitsu Desktop PC to test it.
Without this PATCH, it failed to kexec and kdump.
With this PATCH, it succeed to kexec.
But failed to kdump. From the log, I think it didn't jump to the second
kernel, just reboot after panic. I have not figured out what's the
problem, but it seems not caused by this PATCH.
So I still think this PATCH works for the Fujitsu Desktop PC.
As for your issue, I think there may be some problems related to specified
hardware. Are you using a Lenovo laptop?
And I am not sure how Nomura tested it.
Thanks,
Chao Fan
>
>Thanks,
>Chao Fan
>
>>
>>Thanks
>>Dave
>>
>>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
On 04/03/19 at 04:23pm, Dave Young wrote: > On 04/03/19 at 03:50pm, Baoquan He wrote: > > On 04/03/19 at 03:30pm, Chao Fan wrote: > > > On Wed, Apr 03, 2019 at 02:39:11PM +0800, Dave Young wrote: > > > >> Actually I got some different kexec test results. > > > >> > > > >> Yesterday, with my installed kernel (based on git head several weeks > > > >> ago), kexec kernel panics. > > > >> > > > >> Then I tried latest mainline with git pull, everything works, (with or > > > >> without the patch, and can not reproduce the bug this patch is fixing) > > > >> > > > >> Today, test again, kexec reboot hangs (with or without your patch), but > > > >> kdump works always (with or without the patch) > > > >> > > > >> It is weird to me. Probably I need find out why I can not reproduce the > > > >> bug this patch is addressing first. > > > >> > > > >> earlyprintk seems not working for me anymore, it is not easy to debug > > > >> on > > > >> laptop now. > > > >> > > > >> But the patch itself is clear, I think it should be good. There might > > > >> be > > > >> other things broken. > > > > > > > >Disable your immovable mem code then everything works for me. There > > > >might be something wrong in the code. Also "nokaslr" does not help, it > > > >should be another problem > > > > > > If "nokaslr" doesn't help, so I think > > > >+ /*num_immovable_mem = count_immovable_mem_regions();*/ > > > also doesn't help. I think the problem is from get_rsdp_addr(). > > > > Yes, seems get_rsdp_addr() has issue in this case. I am wondering if we > > can adjust the postion of get_rsdp_addr() calling. If nokaslr is > > specified, no need to get rsdp? > > I assumed the early code is only be useful for kaslr, if this is true > then no need to get rsdp in case nokaslr. > > But I vaguely remember Boris want the boot_params rsdp pointer be a > general thing, I did not followed up these patch discussions, need to see how > Boris thinks about this. > Personally I would like to have a cmdline to bypass the early acpi code because early code is hard to debug, if we have something weird happens we can try to gate out these code, and then get some idea.. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
On 04/03/19 at 03:50pm, Baoquan He wrote: > On 04/03/19 at 03:30pm, Chao Fan wrote: > > On Wed, Apr 03, 2019 at 02:39:11PM +0800, Dave Young wrote: > > >> Actually I got some different kexec test results. > > >> > > >> Yesterday, with my installed kernel (based on git head several weeks > > >> ago), kexec kernel panics. > > >> > > >> Then I tried latest mainline with git pull, everything works, (with or > > >> without the patch, and can not reproduce the bug this patch is fixing) > > >> > > >> Today, test again, kexec reboot hangs (with or without your patch), but > > >> kdump works always (with or without the patch) > > >> > > >> It is weird to me. Probably I need find out why I can not reproduce the > > >> bug this patch is addressing first. > > >> > > >> earlyprintk seems not working for me anymore, it is not easy to debug on > > >> laptop now. > > >> > > >> But the patch itself is clear, I think it should be good. There might be > > >> other things broken. > > > > > >Disable your immovable mem code then everything works for me. There > > >might be something wrong in the code. Also "nokaslr" does not help, it > > >should be another problem > > > > If "nokaslr" doesn't help, so I think > > >+ /*num_immovable_mem = count_immovable_mem_regions();*/ > > also doesn't help. I think the problem is from get_rsdp_addr(). > > Yes, seems get_rsdp_addr() has issue in this case. I am wondering if we > can adjust the postion of get_rsdp_addr() calling. If nokaslr is > specified, no need to get rsdp? I assumed the early code is only be useful for kaslr, if this is true then no need to get rsdp in case nokaslr. But I vaguely remember Boris want the boot_params rsdp pointer be a general thing, I did not followed up these patch discussions, need to see how Boris thinks about this. Thanks Dave ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
On Wed, Apr 03, 2019 at 04:09:16PM +0800, Dave Young wrote:
>On 04/03/19 at 03:21pm, Chao Fan wrote:
>> On Wed, Apr 03, 2019 at 01:53:40PM +0800, Dave Young wrote:
>> >On 04/03/19 at 01:35pm, Chao Fan wrote:
>> >> On Tue, Apr 02, 2019 at 08:03:19PM +0800, Dave Young wrote:
>> >> >On 04/01/19 at 12:08am, Junichi Nomura wrote:
>> >> >> Commit 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in
>> >> >> boot_params") broke kexec boot on EFI systems. efi_get_rsdp_addr()
>> >> >> in the early parsing code tries to search RSDP from EFI table but
>> >> >> that will crash because the table address is virtual when the kernel
>> >> >> was booted by kexec.
>> >> >>
>> >> >> In the case of kexec, physical address of EFI tables is provided
>> >> >> via efi_setup_data in boot_params, which is set up by kexec(1).
>> >> >>
>> >> >> Factor out the table parsing code and use different pointers depending
>> >> >> on whether the kernel is booted by kexec or not.
>> >> >>
>> >> >> Fixes: 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in
>> >> >> boot_params")
>> >> >> Signed-off-by: Jun'ichi Nomura
>> >> >> Acked-by: Baoquan He
>> >> >> Cc: Chao Fan
>> >> >> Cc: Borislav Petkov
>> >> >> Cc: Dave Young
>> >> [...]
>> >> >
>> >> >I failed to kexec reboot on my laptop, kernel panics too quick, I'm not
>> >> >sure this is
>> >> >caused by your patch though.
>> >> >
>> >> >Actually there are something probably i915 changes break kexec, the
>> >> >above test is with "nomodeset" which should work.
>> >> >
>> >> >Let me do more testing and update here tomorrow.
>> >> >
>> >>
>> >> Hi Dave,
>> >>
>> >> Last day I was testing the normal kexec, today I have tested the kdump
>> >> issue. Since the kdump has set "nokaslr" to cmdline, so I drop from
>> >> KDUMP_COMMANDLINE_APPEND
>> >> And it booted OK, so the PATCH works in both normal kexec and kdump.
>> >>
>> >
>> >Actually I got some different kexec test results.
>> >
>> >Yesterday, with my installed kernel (based on git head several weeks
>> >ago), kexec kernel panics.
>> >
>> >Then I tried latest mainline with git pull, everything works, (with or
>> >without the patch, and can not reproduce the bug this patch is fixing)
>> >
>> >Today, test again, kexec reboot hangs (with or without your patch), but
>> >kdump works always (with or without the patch)
>>
>> That's so strange, I'm puzzled by your test.
>> Withour ant changes, just test again, the result of yesterday and today
>> are different?
>>
>> >
>> >It is weird to me. Probably I need find out why I can not reproduce the
>> >bug this patch is addressing first.
>>
>> Hmm, is your laptop booted from EFI or legacy BIOS?
>
>EFI booted.
>
>> >
>> >earlyprintk seems not working for me anymore, it is not easy to debug on
>> >laptop now.
>>
>> Another computer can help print the console message.
>> I remeber you are good at debug on two computers.
>
>I used to use earlyprintk, but seems earlyprintk can not work so early.
>So I only can try to comment out code manually.
Ah, I got it. If you want to use earlyprintk to print message of
get_rsdp_addr(), you should change some code.
Because get_rsdp_addr() is called before earlyprintk initialed.
I am still testing, but in my debug stage, I change like this:
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index c0d6c560df69..dbbe8d9a5792 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -352,7 +352,6 @@ asmlinkage __visible void *extract_kernel(void *rmode,
memptr heap,
boot_params->hdr.loadflags &= ~KASLR_FLAG;
/* Save RSDP address for later use. */
- boot_params->acpi_rsdp_addr = get_rsdp_addr();
sanitize_boot_params(boot_params);
@@ -368,6 +367,7 @@ asmlinkage __visible void *extract_kernel(void *rmode,
memptr heap,
cols = boot_params->screen_info.orig_video_cols;
console_init();
+ boot_params->acpi_rsdp_addr = get_rsdp_addr();
debug_putstr("early console in extract_kernel\n");
free_mem_ptr = heap;/* Heap */
Call this function after console_init().
That will make earlyprintk works.
>
>It seems to be still some bug in early acpi code because if I
>return 0 in get rsdp function it just works.
>
>This guess make sense to me for now:
>1. nokaslr does not work because it may only avoid randomization, but it
>does not avoid running the early acpi parsing code.
>
>2. kexec does not work without the patch we talked about, because I just
>reproduced Junichi reported bug, sometimes hang, or reset, it is
>understandable.
>
>3. kexec does not work with the patch, so there is still bugs in the
>code.
>
>So several things to do is:
>
>Fix 1. (separate issue), Baoquan or either of you may want to fix it :)
For 1, I think it's not needed to fix. Since not only KASLR needs RSDP.
So nokaslr should not stop the acpi parsing code.
>
>Fix 3. need more debugging, have you or Junichi run tests on more real
>hardware,
Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
> > > >Today, test again, kexec reboot hangs (with or without your patch), but > >kdump works always (with or without the patch) > > That's so strange, I'm puzzled by your test. > Withour ant changes, just test again, the result of yesterday and today > are different? > Yes, I'm also puzzled, not 100% sure if I have some wrong test steps or something, can only say for today's test results now :( ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
On 04/03/19 at 03:21pm, Chao Fan wrote:
> On Wed, Apr 03, 2019 at 01:53:40PM +0800, Dave Young wrote:
> >On 04/03/19 at 01:35pm, Chao Fan wrote:
> >> On Tue, Apr 02, 2019 at 08:03:19PM +0800, Dave Young wrote:
> >> >On 04/01/19 at 12:08am, Junichi Nomura wrote:
> >> >> Commit 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in
> >> >> boot_params") broke kexec boot on EFI systems. efi_get_rsdp_addr()
> >> >> in the early parsing code tries to search RSDP from EFI table but
> >> >> that will crash because the table address is virtual when the kernel
> >> >> was booted by kexec.
> >> >>
> >> >> In the case of kexec, physical address of EFI tables is provided
> >> >> via efi_setup_data in boot_params, which is set up by kexec(1).
> >> >>
> >> >> Factor out the table parsing code and use different pointers depending
> >> >> on whether the kernel is booted by kexec or not.
> >> >>
> >> >> Fixes: 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in
> >> >> boot_params")
> >> >> Signed-off-by: Jun'ichi Nomura
> >> >> Acked-by: Baoquan He
> >> >> Cc: Chao Fan
> >> >> Cc: Borislav Petkov
> >> >> Cc: Dave Young
> >> [...]
> >> >
> >> >I failed to kexec reboot on my laptop, kernel panics too quick, I'm not
> >> >sure this is
> >> >caused by your patch though.
> >> >
> >> >Actually there are something probably i915 changes break kexec, the
> >> >above test is with "nomodeset" which should work.
> >> >
> >> >Let me do more testing and update here tomorrow.
> >> >
> >>
> >> Hi Dave,
> >>
> >> Last day I was testing the normal kexec, today I have tested the kdump
> >> issue. Since the kdump has set "nokaslr" to cmdline, so I drop from
> >> KDUMP_COMMANDLINE_APPEND
> >> And it booted OK, so the PATCH works in both normal kexec and kdump.
> >>
> >
> >Actually I got some different kexec test results.
> >
> >Yesterday, with my installed kernel (based on git head several weeks
> >ago), kexec kernel panics.
> >
> >Then I tried latest mainline with git pull, everything works, (with or
> >without the patch, and can not reproduce the bug this patch is fixing)
> >
> >Today, test again, kexec reboot hangs (with or without your patch), but
> >kdump works always (with or without the patch)
>
> That's so strange, I'm puzzled by your test.
> Withour ant changes, just test again, the result of yesterday and today
> are different?
>
> >
> >It is weird to me. Probably I need find out why I can not reproduce the
> >bug this patch is addressing first.
>
> Hmm, is your laptop booted from EFI or legacy BIOS?
EFI booted.
> >
> >earlyprintk seems not working for me anymore, it is not easy to debug on
> >laptop now.
>
> Another computer can help print the console message.
> I remeber you are good at debug on two computers.
I used to use earlyprintk, but seems earlyprintk can not work so early.
So I only can try to comment out code manually.
It seems to be still some bug in early acpi code because if I
return 0 in get rsdp function it just works.
This guess make sense to me for now:
1. nokaslr does not work because it may only avoid randomization, but it
does not avoid running the early acpi parsing code.
2. kexec does not work without the patch we talked about, because I just
reproduced Junichi reported bug, sometimes hang, or reset, it is
understandable.
3. kexec does not work with the patch, so there is still bugs in the
code.
So several things to do is:
Fix 1. (separate issue), Baoquan or either of you may want to fix it :)
Fix 3. need more debugging, have you or Junichi run tests on more real
hardware, maybe it is easier to reproduce on real hardware, I'm glad to
help to try test patch or provide any help.
Thanks
Dave
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
On 04/03/19 at 03:30pm, Chao Fan wrote: > On Wed, Apr 03, 2019 at 02:39:11PM +0800, Dave Young wrote: > >> Actually I got some different kexec test results. > >> > >> Yesterday, with my installed kernel (based on git head several weeks > >> ago), kexec kernel panics. > >> > >> Then I tried latest mainline with git pull, everything works, (with or > >> without the patch, and can not reproduce the bug this patch is fixing) > >> > >> Today, test again, kexec reboot hangs (with or without your patch), but > >> kdump works always (with or without the patch) > >> > >> It is weird to me. Probably I need find out why I can not reproduce the > >> bug this patch is addressing first. > >> > >> earlyprintk seems not working for me anymore, it is not easy to debug on > >> laptop now. > >> > >> But the patch itself is clear, I think it should be good. There might be > >> other things broken. > > > >Disable your immovable mem code then everything works for me. There > >might be something wrong in the code. Also "nokaslr" does not help, it > >should be another problem > > If "nokaslr" doesn't help, so I think > >+ /*num_immovable_mem = count_immovable_mem_regions();*/ > also doesn't help. I think the problem is from get_rsdp_addr(). Yes, seems get_rsdp_addr() has issue in this case. I am wondering if we can adjust the postion of get_rsdp_addr() calling. If nokaslr is specified, no need to get rsdp? > > You test it in your laptop, I only tested in Qemu guest. > I have no laptop avaliable, so I will look for a physical machine > to test it. > > Thanks, > Chao Fan > > > > >diff --git a/arch/x86/boot/compressed/kaslr.c > >b/arch/x86/boot/compressed/kaslr.c > >index 2e53c056ba20..e760c9159662 100644 > >--- a/arch/x86/boot/compressed/kaslr.c > >+++ b/arch/x86/boot/compressed/kaslr.c > >@@ -416,7 +416,7 @@ static void mem_avoid_init(unsigned long input, unsigned > >long input_size, > > handle_mem_options(); > > > > /* Enumerate the immovable memory regions */ > >-num_immovable_mem = count_immovable_mem_regions(); > >+/*num_immovable_mem = count_immovable_mem_regions();*/ > > > > #ifdef CONFIG_X86_VERBOSE_BOOTUP > > /* Make sure video RAM can be used. */ > >diff --git a/arch/x86/boot/compressed/misc.c > >b/arch/x86/boot/compressed/misc.c > >index c0d6c560df69..1bc6f46d3aa7 100644 > >--- a/arch/x86/boot/compressed/misc.c > >+++ b/arch/x86/boot/compressed/misc.c > >@@ -352,7 +352,7 @@ asmlinkage __visible void *extract_kernel(void *rmode, > >memptr heap, > > boot_params->hdr.loadflags &= ~KASLR_FLAG; > > > > /* Save RSDP address for later use. */ > >-boot_params->acpi_rsdp_addr = get_rsdp_addr(); > >+/* boot_params->acpi_rsdp_addr = get_rsdp_addr(); */ > > > > sanitize_boot_params(boot_params); > > > > > > > > ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
On Wed, Apr 03, 2019 at 02:39:11PM +0800, Dave Young wrote: >> Actually I got some different kexec test results. >> >> Yesterday, with my installed kernel (based on git head several weeks >> ago), kexec kernel panics. >> >> Then I tried latest mainline with git pull, everything works, (with or >> without the patch, and can not reproduce the bug this patch is fixing) >> >> Today, test again, kexec reboot hangs (with or without your patch), but >> kdump works always (with or without the patch) >> >> It is weird to me. Probably I need find out why I can not reproduce the >> bug this patch is addressing first. >> >> earlyprintk seems not working for me anymore, it is not easy to debug on >> laptop now. >> >> But the patch itself is clear, I think it should be good. There might be >> other things broken. > >Disable your immovable mem code then everything works for me. There >might be something wrong in the code. Also "nokaslr" does not help, it >should be another problem If "nokaslr" doesn't help, so I think >+ /*num_immovable_mem = count_immovable_mem_regions();*/ also doesn't help. I think the problem is from get_rsdp_addr(). You test it in your laptop, I only tested in Qemu guest. I have no laptop avaliable, so I will look for a physical machine to test it. Thanks, Chao Fan > >diff --git a/arch/x86/boot/compressed/kaslr.c >b/arch/x86/boot/compressed/kaslr.c >index 2e53c056ba20..e760c9159662 100644 >--- a/arch/x86/boot/compressed/kaslr.c >+++ b/arch/x86/boot/compressed/kaslr.c >@@ -416,7 +416,7 @@ static void mem_avoid_init(unsigned long input, unsigned >long input_size, > handle_mem_options(); > > /* Enumerate the immovable memory regions */ >- num_immovable_mem = count_immovable_mem_regions(); >+ /*num_immovable_mem = count_immovable_mem_regions();*/ > > #ifdef CONFIG_X86_VERBOSE_BOOTUP > /* Make sure video RAM can be used. */ >diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c >index c0d6c560df69..1bc6f46d3aa7 100644 >--- a/arch/x86/boot/compressed/misc.c >+++ b/arch/x86/boot/compressed/misc.c >@@ -352,7 +352,7 @@ asmlinkage __visible void *extract_kernel(void *rmode, >memptr heap, > boot_params->hdr.loadflags &= ~KASLR_FLAG; > > /* Save RSDP address for later use. */ >- boot_params->acpi_rsdp_addr = get_rsdp_addr(); >+/*boot_params->acpi_rsdp_addr = get_rsdp_addr(); */ > > sanitize_boot_params(boot_params); > > > ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
On Wed, Apr 03, 2019 at 01:53:40PM +0800, Dave Young wrote:
>On 04/03/19 at 01:35pm, Chao Fan wrote:
>> On Tue, Apr 02, 2019 at 08:03:19PM +0800, Dave Young wrote:
>> >On 04/01/19 at 12:08am, Junichi Nomura wrote:
>> >> Commit 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in
>> >> boot_params") broke kexec boot on EFI systems. efi_get_rsdp_addr()
>> >> in the early parsing code tries to search RSDP from EFI table but
>> >> that will crash because the table address is virtual when the kernel
>> >> was booted by kexec.
>> >>
>> >> In the case of kexec, physical address of EFI tables is provided
>> >> via efi_setup_data in boot_params, which is set up by kexec(1).
>> >>
>> >> Factor out the table parsing code and use different pointers depending
>> >> on whether the kernel is booted by kexec or not.
>> >>
>> >> Fixes: 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in
>> >> boot_params")
>> >> Signed-off-by: Jun'ichi Nomura
>> >> Acked-by: Baoquan He
>> >> Cc: Chao Fan
>> >> Cc: Borislav Petkov
>> >> Cc: Dave Young
>> [...]
>> >
>> >I failed to kexec reboot on my laptop, kernel panics too quick, I'm not
>> >sure this is
>> >caused by your patch though.
>> >
>> >Actually there are something probably i915 changes break kexec, the
>> >above test is with "nomodeset" which should work.
>> >
>> >Let me do more testing and update here tomorrow.
>> >
>>
>> Hi Dave,
>>
>> Last day I was testing the normal kexec, today I have tested the kdump
>> issue. Since the kdump has set "nokaslr" to cmdline, so I drop from
>> KDUMP_COMMANDLINE_APPEND
>> And it booted OK, so the PATCH works in both normal kexec and kdump.
>>
>
>Actually I got some different kexec test results.
>
>Yesterday, with my installed kernel (based on git head several weeks
>ago), kexec kernel panics.
>
>Then I tried latest mainline with git pull, everything works, (with or
>without the patch, and can not reproduce the bug this patch is fixing)
>
>Today, test again, kexec reboot hangs (with or without your patch), but
>kdump works always (with or without the patch)
That's so strange, I'm puzzled by your test.
Withour ant changes, just test again, the result of yesterday and today
are different?
>
>It is weird to me. Probably I need find out why I can not reproduce the
>bug this patch is addressing first.
Hmm, is your laptop booted from EFI or legacy BIOS?
>
>earlyprintk seems not working for me anymore, it is not easy to debug on
>laptop now.
Another computer can help print the console message.
I remeber you are good at debug on two computers.
Thanks,
Chao Fan
>
>But the patch itself is clear, I think it should be good. There might be
>other things broken.
>
>Thanks
>Dave
>
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
On 04/03/19 at 01:53pm, Dave Young wrote:
> On 04/03/19 at 01:35pm, Chao Fan wrote:
> > On Tue, Apr 02, 2019 at 08:03:19PM +0800, Dave Young wrote:
> > >On 04/01/19 at 12:08am, Junichi Nomura wrote:
> > >> Commit 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in
> > >> boot_params") broke kexec boot on EFI systems. efi_get_rsdp_addr()
> > >> in the early parsing code tries to search RSDP from EFI table but
> > >> that will crash because the table address is virtual when the kernel
> > >> was booted by kexec.
> > >>
> > >> In the case of kexec, physical address of EFI tables is provided
> > >> via efi_setup_data in boot_params, which is set up by kexec(1).
> > >>
> > >> Factor out the table parsing code and use different pointers depending
> > >> on whether the kernel is booted by kexec or not.
> > >>
> > >> Fixes: 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in
> > >> boot_params")
> > >> Signed-off-by: Jun'ichi Nomura
> > >> Acked-by: Baoquan He
> > >> Cc: Chao Fan
> > >> Cc: Borislav Petkov
> > >> Cc: Dave Young
> > [...]
> > >
> > >I failed to kexec reboot on my laptop, kernel panics too quick, I'm not
> > >sure this is
> > >caused by your patch though.
> > >
> > >Actually there are something probably i915 changes break kexec, the
> > >above test is with "nomodeset" which should work.
> > >
> > >Let me do more testing and update here tomorrow.
> > >
> >
> > Hi Dave,
> >
> > Last day I was testing the normal kexec, today I have tested the kdump
> > issue. Since the kdump has set "nokaslr" to cmdline, so I drop from
> > KDUMP_COMMANDLINE_APPEND
> > And it booted OK, so the PATCH works in both normal kexec and kdump.
> >
>
> Actually I got some different kexec test results.
>
> Yesterday, with my installed kernel (based on git head several weeks
> ago), kexec kernel panics.
>
> Then I tried latest mainline with git pull, everything works, (with or
> without the patch, and can not reproduce the bug this patch is fixing)
>
> Today, test again, kexec reboot hangs (with or without your patch), but
> kdump works always (with or without the patch)
>
> It is weird to me. Probably I need find out why I can not reproduce the
> bug this patch is addressing first.
>
> earlyprintk seems not working for me anymore, it is not easy to debug on
> laptop now.
>
> But the patch itself is clear, I think it should be good. There might be
> other things broken.
Disable your immovable mem code then everything works for me. There
might be something wrong in the code. Also "nokaslr" does not help, it
should be another problem
diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 2e53c056ba20..e760c9159662 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -416,7 +416,7 @@ static void mem_avoid_init(unsigned long input, unsigned
long input_size,
handle_mem_options();
/* Enumerate the immovable memory regions */
- num_immovable_mem = count_immovable_mem_regions();
+ /*num_immovable_mem = count_immovable_mem_regions();*/
#ifdef CONFIG_X86_VERBOSE_BOOTUP
/* Make sure video RAM can be used. */
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index c0d6c560df69..1bc6f46d3aa7 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -352,7 +352,7 @@ asmlinkage __visible void *extract_kernel(void *rmode,
memptr heap,
boot_params->hdr.loadflags &= ~KASLR_FLAG;
/* Save RSDP address for later use. */
- boot_params->acpi_rsdp_addr = get_rsdp_addr();
+/* boot_params->acpi_rsdp_addr = get_rsdp_addr(); */
sanitize_boot_params(boot_params);
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
On 04/03/19 at 01:35pm, Chao Fan wrote:
> On Tue, Apr 02, 2019 at 08:03:19PM +0800, Dave Young wrote:
> >On 04/01/19 at 12:08am, Junichi Nomura wrote:
> >> Commit 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in
> >> boot_params") broke kexec boot on EFI systems. efi_get_rsdp_addr()
> >> in the early parsing code tries to search RSDP from EFI table but
> >> that will crash because the table address is virtual when the kernel
> >> was booted by kexec.
> >>
> >> In the case of kexec, physical address of EFI tables is provided
> >> via efi_setup_data in boot_params, which is set up by kexec(1).
> >>
> >> Factor out the table parsing code and use different pointers depending
> >> on whether the kernel is booted by kexec or not.
> >>
> >> Fixes: 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in
> >> boot_params")
> >> Signed-off-by: Jun'ichi Nomura
> >> Acked-by: Baoquan He
> >> Cc: Chao Fan
> >> Cc: Borislav Petkov
> >> Cc: Dave Young
> [...]
> >
> >I failed to kexec reboot on my laptop, kernel panics too quick, I'm not
> >sure this is
> >caused by your patch though.
> >
> >Actually there are something probably i915 changes break kexec, the
> >above test is with "nomodeset" which should work.
> >
> >Let me do more testing and update here tomorrow.
> >
>
> Hi Dave,
>
> Last day I was testing the normal kexec, today I have tested the kdump
> issue. Since the kdump has set "nokaslr" to cmdline, so I drop from
> KDUMP_COMMANDLINE_APPEND
> And it booted OK, so the PATCH works in both normal kexec and kdump.
>
Actually I got some different kexec test results.
Yesterday, with my installed kernel (based on git head several weeks
ago), kexec kernel panics.
Then I tried latest mainline with git pull, everything works, (with or
without the patch, and can not reproduce the bug this patch is fixing)
Today, test again, kexec reboot hangs (with or without your patch), but
kdump works always (with or without the patch)
It is weird to me. Probably I need find out why I can not reproduce the
bug this patch is addressing first.
earlyprintk seems not working for me anymore, it is not easy to debug on
laptop now.
But the patch itself is clear, I think it should be good. There might be
other things broken.
Thanks
Dave
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
On Tue, Apr 02, 2019 at 08:03:19PM +0800, Dave Young wrote:
>On 04/01/19 at 12:08am, Junichi Nomura wrote:
>> Commit 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in
>> boot_params") broke kexec boot on EFI systems. efi_get_rsdp_addr()
>> in the early parsing code tries to search RSDP from EFI table but
>> that will crash because the table address is virtual when the kernel
>> was booted by kexec.
>>
>> In the case of kexec, physical address of EFI tables is provided
>> via efi_setup_data in boot_params, which is set up by kexec(1).
>>
>> Factor out the table parsing code and use different pointers depending
>> on whether the kernel is booted by kexec or not.
>>
>> Fixes: 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in
>> boot_params")
>> Signed-off-by: Jun'ichi Nomura
>> Acked-by: Baoquan He
>> Cc: Chao Fan
>> Cc: Borislav Petkov
>> Cc: Dave Young
[...]
>
>I failed to kexec reboot on my laptop, kernel panics too quick, I'm not sure
>this is
>caused by your patch though.
>
>Actually there are something probably i915 changes break kexec, the
>above test is with "nomodeset" which should work.
>
>Let me do more testing and update here tomorrow.
>
Hi Dave,
Last day I was testing the normal kexec, today I have tested the kdump
issue. Since the kdump has set "nokaslr" to cmdline, so I drop from
KDUMP_COMMANDLINE_APPEND
And it booted OK, so the PATCH works in both normal kexec and kdump.
[root@localhost ~]# echo 1 > /proc/sys/kernel/sysrq
[root@localhost ~]# echo c > /proc/sysrq-trigger
[ 67.776136] sysrq: Trigger a crash
[ 67.777412] Kernel panic - not syncing: sysrq triggered crash
[ 67.779429] CPU: 1 PID: 1652 Comm: bash Kdump: loaded Not tainted 5.1.0-rc3+
#4
[ 67.780755] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
0.0.0 02/06/2015
[ 67.782062] Call Trace:
[ 67.782490] dump_stack+0x5c/0x80
[ 67.783049] panic+0x101/0x2a7
[ 67.783560] ? printk+0x58/0x6f
[ 67.784091] sysrq_handle_crash+0x11/0x11
[ 67.784762] __handle_sysrq.cold.7+0x45/0xf2
[ 67.785467] write_sysrq_trigger+0x2b/0x30
[ 67.786087] proc_reg_write+0x39/0x60
[ 67.786597] vfs_write+0xa5/0x1a0
[ 67.787061] ksys_write+0x4f/0xb0
[ 67.787492] do_syscall_64+0x5b/0x160
[ 67.788010] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 67.788740] RIP: 0033:0x7f66266fbed8
[ 67.789239] Code: 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 f3
0f 1e fa 48 8d 05 45 78 0d 00 8b 00 85 c0 75 17 b8 01 00 00 00 0f 05 <48> 3d 00
f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 49 89 d4 55
[ 67.791325] RSP: 002b:7ffecdaf6138 EFLAGS: 0246 ORIG_RAX:
0001
[ 67.792084] RAX: ffda RBX: 0002 RCX: 7f66266fbed8
[ 67.792820] RDX: 0002 RSI: 55dcc8d29880 RDI: 0001
[ 67.793515] RBP: 55dcc8d29880 R08: 000a R09: 7ffecdaf5cc0
[ 67.794276] R10: 000a R11: 0246 R12: 7f66267cf780
[ 67.795017] R13: 0002 R14: 7f66267ca740 R15: 0002
early console in extract_kernel
input_data: 0x376033b1
input_len: 0x008412d4
output: 0x3600
output_len: 0x01e15844
kernel_total_size: 0x01e2c000
trampoline_32bit: 0x0009d000
booted via startup_64()
Physical KASLR disabled: no suitable memory region!
Virtual KASLR using RDRAND RDTSC...
Decompressing Linux... Parsing ELF... Performing relocations... done.
Booting the kernel.
[...]
Starting Kdump Vmcore Save Service...
kdump: dump target is /dev/mapper/fedora-root
kdump: saving to /sysroot//var/crash/127.0.0.1-2019-04-03-01:28:01/
[3.551609] EXT4-fs (dm-0): re-mounted. Opts: (null)
kdump: saving vmcore-dmesg.txt
kdump: saving vmcore-dmesg.txt complete
kdump: saving vmcore
Copying data : [100.0 %] | eta:
0s
kdump: saving vmcore complete
Thanks,
Chao Fan
>Thanks
>Dave
>
>
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
On 4/2/19 8:06 PM, Chao Fan wrote: > On Tue, Apr 02, 2019 at 09:53:51AM +, Junichi Nomura wrote: >> On Tue, Apr 02, 2019 at 05:41:49PM +0800, Chao Fan wrote: >>> [ 77.989030] kexec_core: Starting new kernel >>> early console in extract_kernel >>> input_data: 0x00017f6033b1 >>> input_len: 0x008412d4 >>> output: 0x00017e00 >>> output_len: 0x01e15844 >>> kernel_total_size: 0x01e2c000 >>> trampoline_32bit: 0x0009d000 >>> booted via startup_64() >>> >>> >>> Physical KASLR disabled: no suitable memory region! >>> -- >>> >>> I am not sure whether I have done the right test. >>> This guest is booted from EFI. Here we can see the kexeced kernel >>> has completed the compressed boot stage. So I think your PATCH works. >> >> Thanks for testing. If your test bed doesn't boot even with the patch, >> you could check what was found as RSDP with a debug patch like below. > > Oh no, it booted. I just put the compressed stag log. Ah, then I think the patch worked as expected. Thanks. -- Jun'ichi Nomura, NEC Corporation / NEC Solution Innovators, Ltd. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
On Tue, Apr 02, 2019 at 09:53:51AM +, Junichi Nomura wrote: >On Tue, Apr 02, 2019 at 05:41:49PM +0800, Chao Fan wrote: >> [ 77.989030] kexec_core: Starting new kernel >> early console in extract_kernel >> input_data: 0x00017f6033b1 >> input_len: 0x008412d4 >> output: 0x00017e00 >> output_len: 0x01e15844 >> kernel_total_size: 0x01e2c000 >> trampoline_32bit: 0x0009d000 >> booted via startup_64() >> >> >> Physical KASLR disabled: no suitable memory region! >> -- >> >> I am not sure whether I have done the right test. >> This guest is booted from EFI. Here we can see the kexeced kernel >> has completed the compressed boot stage. So I think your PATCH works. > >Thanks for testing. If your test bed doesn't boot even with the patch, >you could check what was found as RSDP with a debug patch like below. Oh no, it booted. I just put the compressed stag log. Thanks, Chao Fan > >diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c >--- a/arch/x86/boot/compressed/misc.c >+++ b/arch/x86/boot/compressed/misc.c >@@ -379,6 +379,7 @@ asmlinkage __visible void *extract_kernel(void *rmode, >memptr heap, > debug_putaddr(output); > debug_putaddr(output_len); > debug_putaddr(kernel_total_size); >+ debug_putaddr(boot_params->acpi_rsdp_addr); > > #ifdef CONFIG_X86_64 > /* Report address of 32-bit trampoline */ > > ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
On Tue, Apr 02, 2019 at 05:41:49PM +0800, Chao Fan wrote: > [ 77.989030] kexec_core: Starting new kernel > early console in extract_kernel > input_data: 0x00017f6033b1 > input_len: 0x008412d4 > output: 0x00017e00 > output_len: 0x01e15844 > kernel_total_size: 0x01e2c000 > trampoline_32bit: 0x0009d000 > booted via startup_64() > > > Physical KASLR disabled: no suitable memory region! > -- > > I am not sure whether I have done the right test. > This guest is booted from EFI. Here we can see the kexeced kernel > has completed the compressed boot stage. So I think your PATCH works. Thanks for testing. If your test bed doesn't boot even with the patch, you could check what was found as RSDP with a debug patch like below. diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c --- a/arch/x86/boot/compressed/misc.c +++ b/arch/x86/boot/compressed/misc.c @@ -379,6 +379,7 @@ asmlinkage __visible void *extract_kernel(void *rmode, memptr heap, debug_putaddr(output); debug_putaddr(output_len); debug_putaddr(kernel_total_size); + debug_putaddr(boot_params->acpi_rsdp_addr); #ifdef CONFIG_X86_64 /* Report address of 32-bit trampoline */ ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
Hi, I have test your PATCH in Qemu guest: -- Fedora 29 (Workstation Edition) Kernel 5.1.0-rc3+ on an x86_64 (ttyS0) localhost login: root Password: Last login: Tue Apr 2 05:30:33 on ttyS0 [root@localhost ~]# cd /boot [root@localhost boot]# ls config-4.18.16-300.fc29.x86_64 efi extlinux grub2 initramfs-0-rescue-858ff1f5d0cb453898ae6c7f77c68ba7.img initramfs-4.18.16-300.fc29.x86_64.img initramfs-4.18.16-300.fc29.x86_64kdump.img initramfs-5.1.0-rc3+.img initramfs-5.1.0-rc3+kdump.img loader lost+found System.map System.map-4.18.16-300.fc29.x86_64 System.map-5.1.0-rc3+ vmlinuz vmlinuz-0-rescue-858ff1f5d0cb453898ae6c7f77c68ba7 vmlinuz-4.18.16-300.fc29.x86_64 vmlinuz-5.1.0-rc3+ [root@localhost boot]# kexec -l vmlinuz-5.1.0-rc3+ --initrd=initramfs-5.1.0-rc3+.img --reuse-cmdline [root@localhost boot]# kexec -e [ 77.933760] Unregister pv shared memory for cpu 1 [ 77.933763] Unregister pv shared memory for cpu 2 [ 77.933766] Unregister pv shared memory for cpu 5 [ 77.933825] Unregister pv shared memory for cpu 7 [ 77.933882] Unregister pv shared memory for cpu 3 [ 77.933904] Unregister pv shared memory for cpu 8 [ 77.936147] Unregister pv shared memory for cpu 4 [ 77.936199] Unregister pv shared memory for cpu 9 [ 77.945822] Unregister pv shared memory for cpu 0 [ 77.946308] Unregister pv shared memory for cpu 6 [ 77.947420] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 77.989030] kexec_core: Starting new kernel early console in extract_kernel input_data: 0x00017f6033b1 input_len: 0x008412d4 output: 0x00017e00 output_len: 0x01e15844 kernel_total_size: 0x01e2c000 trampoline_32bit: 0x0009d000 booted via startup_64() Physical KASLR disabled: no suitable memory region! -- I am not sure whether I have done the right test. This guest is booted from EFI. Here we can see the kexeced kernel has completed the compressed boot stage. So I think your PATCH works. Thanks, Chao Fan ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel
Commit 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in
boot_params") broke kexec boot on EFI systems. efi_get_rsdp_addr()
in the early parsing code tries to search RSDP from EFI table but
that will crash because the table address is virtual when the kernel
was booted by kexec.
In the case of kexec, physical address of EFI tables is provided
via efi_setup_data in boot_params, which is set up by kexec(1).
Factor out the table parsing code and use different pointers depending
on whether the kernel is booted by kexec or not.
Fixes: 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in boot_params")
Signed-off-by: Jun'ichi Nomura
Acked-by: Baoquan He
Cc: Chao Fan
Cc: Borislav Petkov
Cc: Dave Young
--
v2: Added comments above __efi_get_rsdp_addr() and kexec_get_rsdp_addr()
diff --git a/arch/x86/boot/compressed/acpi.c b/arch/x86/boot/compressed/acpi.c
--- a/arch/x86/boot/compressed/acpi.c
+++ b/arch/x86/boot/compressed/acpi.c
@@ -44,17 +44,112 @@ static acpi_physical_address get_acpi_rsdp(void)
return addr;
}
-/* Search EFI system tables for RSDP. */
-static acpi_physical_address efi_get_rsdp_addr(void)
+#ifdef CONFIG_EFI
+static unsigned long efi_get_kexec_setup_data_addr(void)
+{
+ struct setup_data *data;
+ u64 pa_data;
+
+ pa_data = boot_params->hdr.setup_data;
+ while (pa_data) {
+ data = (struct setup_data *) pa_data;
+ if (data->type == SETUP_EFI)
+ return pa_data + sizeof(struct setup_data);
+ pa_data = data->next;
+ }
+ return 0;
+}
+
+/*
+ * Search EFI system tables for RSDP. If both ACPI_20_TABLE_GUID and
+ * ACPI_TABLE_GUID are found, take the former, which has more features.
+ */
+static acpi_physical_address
+__efi_get_rsdp_addr(unsigned long config_tables, unsigned int nr_tables,
+ bool efi_64)
{
acpi_physical_address rsdp_addr = 0;
+ int i;
+
+ /* Get EFI tables from systab. */
+ for (i = 0; i < nr_tables; i++) {
+ acpi_physical_address table;
+ efi_guid_t guid;
+
+ if (efi_64) {
+ efi_config_table_64_t *tbl = (efi_config_table_64_t *)
config_tables + i;
+
+ guid = tbl->guid;
+ table = tbl->table;
+
+ if (!IS_ENABLED(CONFIG_X86_64) && table >> 32) {
+ debug_putstr("Error getting RSDP address: EFI
config table located above 4GB.\n");
+ return 0;
+ }
+ } else {
+ efi_config_table_32_t *tbl = (efi_config_table_32_t *)
config_tables + i;
+ guid = tbl->guid;
+ table = tbl->table;
+ }
+
+ if (!(efi_guidcmp(guid, ACPI_TABLE_GUID)))
+ rsdp_addr = table;
+ else if (!(efi_guidcmp(guid, ACPI_20_TABLE_GUID)))
+ return table;
+ }
+
+ return rsdp_addr;
+}
+#endif
+
+/*
+ * EFI/kexec support is only added for 64bit. So we don't have to
+ * care 32bit case.
+ */
+static acpi_physical_address kexec_get_rsdp_addr(void)
+{
#ifdef CONFIG_EFI
- unsigned long systab, systab_tables, config_tables;
+ efi_system_table_64_t *systab;
+ struct efi_setup_data *esd;
+ struct efi_info *ei;
+ char *sig;
+
+ esd = (struct efi_setup_data *) efi_get_kexec_setup_data_addr();
+ if (!esd)
+ return 0;
+
+ if (!esd->tables) {
+ debug_putstr("Wrong kexec SETUP_EFI data.\n");
+ return 0;
+ }
+
+ ei = _params->efi_info;
+ sig = (char *)>efi_loader_signature;
+ if (strncmp(sig, EFI64_LOADER_SIGNATURE, 4)) {
+ debug_putstr("Wrong kexec EFI loader signature.\n");
+ return 0;
+ }
+
+ /* Get systab from boot params. */
+ systab = (efi_system_table_64_t *) (ei->efi_systab |
((__u64)ei->efi_systab_hi << 32));
+ if (!systab)
+ error("EFI system table not found in kexec boot_params.");
+
+ return __efi_get_rsdp_addr((unsigned long) esd->tables,
+ systab->nr_tables, true);
+#else
+ return 0;
+#endif
+}
+
+static acpi_physical_address efi_get_rsdp_addr(void)
+{
+#ifdef CONFIG_EFI
+ unsigned long systab, config_tables;
unsigned int nr_tables;
struct efi_info *ei;
bool efi_64;
- int size, i;
char *sig;
ei = _params->efi_info;
@@ -88,49 +183,20 @@ static acpi_physical_address efi_get_rsdp_addr(void)
config_tables = stbl->tables;
nr_tables = stbl->nr_tables;
- size= sizeof(efi_config_table_64_t);
} else {
efi_system_table_32_t *stbl = (efi_system_table_32_t *)systab;
config_tables = stbl->tables;
