Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel

[Dave Young <dyoung@redhat.com>]

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 <j-nomura@ce.jp.nec.com>
> >> >> Acked-by: Baoquan He <bhe@redhat.com>
> >> >> Cc: Chao Fan <fanc.fnst@cn.fujitsu.com>
> >> >> Cc: Borislav Petkov <bp@suse.de>
> >> >> Cc: Dave Young <dyoung@redhat.com>
> >> [...]
> >> >
> >> >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