Re: EFI stub kexec probelm

[Dave Young]

On 02/16/17 at 03:20pm, Dave Young wrote:
> On 02/16/17 at 07:35pm, Eric W. Biederman wrote:
> > Paweł Lenkow  writes:
> > 
> > > Hi!
> > >
> > > I am trying to run EFI stub kernel using kexec and unfortunately 2nd 
> > > kernel
> > > crashes.
> > 
> > Adding the kexec list as there may be someone there who may be more
> > knowledgeable about our problem.
> > 
> > > First kernel is loaded by UEFI, starts simple init with shell and then
> > > I am loading the same image using kexec.
> > >
> > > It looks like a lack of correct mappings for EFI tables because it
> > > calls address zero (RDI register) in efi_call.
> > >
> > > Does kernel support such configuration?

Yes, it *should* works, at least works for me previously on Lenovo
laptops. What is the hardware in this case?

> > >
> > > If yes what could be wrong?
> > 
> > I don't know exactly where the support is, I haven't looked recently.
> > 
> > There is a major challenge with efi.  The call to place efi in virtual
> > mode may be called exactly once.  There has been work on at least ia64
> > to make it possible to capture the efi virtual address bass and pass it
> > through to the kernel calling kexec.  I don't remember seeing the work
> > to do that happen on other platforms.
> > 
> > I personally think we should just abandon running efi in virtual mode
> > and always run efi in physicall mode, but the feedback when I suggested
> > that was that efi didn't actually work if you did that.  *Shrug*
> > 
> > Given that efi_enter_virtual_mode is in your call trace I am guessing
> > that the problem is the historical problem I have mentioned above.

In latest kernel we have a stable va address space for efi runtime,
kexec-tools will copy the runtime maps in 1st kernel so that efi runtime
still can be still usable after kexec kernel boot up but do not entering
virtual mode again.

There might be some bug either in kernel or some special firmware
problem..

> > 
> > Eric
> > 
> > 
> > 
> > > Using grub-efi all works fine, but it is not enough for me.
> > >
> > > See log below:
> > >
> > >
> > > / # kexec -l /mnt/INSTALL/vmlinuz -s
> 
> What is the kexec-tools version? And does kexec -l works (without -s)?
> 
> A test with efi=debug parameters may help, also full logs of both
> pre-kexec boot and post-kexec boot could also help to find something..

This questions obviously are for Paweł Lenkow, add him to "To" list..

> 
> Thanks
> Dave

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

Re: EFI stub kexec probelm

[Dave Young]

On 02/16/17 at 07:35pm, Eric W. Biederman wrote:
> Paweł Lenkow  writes:
> 
> > Hi!
> >
> > I am trying to run EFI stub kernel using kexec and unfortunately 2nd kernel
> > crashes.
> 
> Adding the kexec list as there may be someone there who may be more
> knowledgeable about our problem.
> 
> > First kernel is loaded by UEFI, starts simple init with shell and then
> > I am loading the same image using kexec.
> >
> > It looks like a lack of correct mappings for EFI tables because it
> > calls address zero (RDI register) in efi_call.
> >
> > Does kernel support such configuration?
> >
> > If yes what could be wrong?
> 
> I don't know exactly where the support is, I haven't looked recently.
> 
> There is a major challenge with efi.  The call to place efi in virtual
> mode may be called exactly once.  There has been work on at least ia64
> to make it possible to capture the efi virtual address bass and pass it
> through to the kernel calling kexec.  I don't remember seeing the work
> to do that happen on other platforms.
> 
> I personally think we should just abandon running efi in virtual mode
> and always run efi in physicall mode, but the feedback when I suggested
> that was that efi didn't actually work if you did that.  *Shrug*
> 
> Given that efi_enter_virtual_mode is in your call trace I am guessing
> that the problem is the historical problem I have mentioned above.
> 
> Eric
> 
> 
> 
> > Using grub-efi all works fine, but it is not enough for me.
> >
> > See log below:
> >
> >
> > / # kexec -l /mnt/INSTALL/vmlinuz -s

What is the kexec-tools version? And does kexec -l works (without -s)?

A test with efi=debug parameters may help, also full logs of both
pre-kexec boot and post-kexec boot could also help to find something..

Thanks
Dave

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

Re: EFI stub kexec probelm

[Eric W. Biederman]

Paweł Lenkow  writes:

> Hi!
>
> I am trying to run EFI stub kernel using kexec and unfortunately 2nd kernel
> crashes.

Adding the kexec list as there may be someone there who may be more
knowledgeable about our problem.

> First kernel is loaded by UEFI, starts simple init with shell and then
> I am loading the same image using kexec.
>
> It looks like a lack of correct mappings for EFI tables because it
> calls address zero (RDI register) in efi_call.
>
> Does kernel support such configuration?
>
> If yes what could be wrong?

I don't know exactly where the support is, I haven't looked recently.

There is a major challenge with efi.  The call to place efi in virtual
mode may be called exactly once.  There has been work on at least ia64
to make it possible to capture the efi virtual address bass and pass it
through to the kernel calling kexec.  I don't remember seeing the work
to do that happen on other platforms.

I personally think we should just abandon running efi in virtual mode
and always run efi in physicall mode, but the feedback when I suggested
that was that efi didn't actually work if you did that.  *Shrug*

Given that efi_enter_virtual_mode is in your call trace I am guessing
that the problem is the historical problem I have mentioned above.

Eric



> Using grub-efi all works fine, but it is not enough for me.
>
> See log below:
>
>
> / # kexec -l /mnt/INSTALL/vmlinuz -s
> / # kexec -e
> [  625.520845] kexec_core: Starting new kernel
> [0.00] Linux version 4.10.0-rc8 (plenkow@plenkow-PC) (gcc version 
> 5.4.0 (GCC) ) #2 SMP Wed Feb 15 09:49:05 CET 2017
> [0.00] Command line:
> [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
> registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
> [0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
> [0.00] x86/fpu: xstate_offset[3]:  832, xstate_sizes[3]:   64
> [0.00] x86/fpu: xstate_offset[4]:  896, xstate_sizes[4]:   64
> [0.00] x86/fpu: Enabled xstate features 0x1f, context size is 960 
> bytes, using 'compacted' format.
> [0.00] e820: BIOS-provided physical RAM map:
> [0.00] BIOS-e820: [mem 0x-0x00057fff] usable
> [0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved
> [0.00] BIOS-e820: [mem 0x00059000-0x00085fff] usable
> [0.00] BIOS-e820: [mem 0x00086000-0x000f] reserved
> [0.00] BIOS-e820: [mem 0x0010-0xa238cfff] usable
> [0.00] BIOS-e820: [mem 0xa238d000-0xa238dfff] ACPI NVS
> [0.00] BIOS-e820: [mem 0xa238e000-0xa23d7fff] reserved
> [0.00] BIOS-e820: [mem 0xa23d8000-0xb867dfff] usable
> [0.00] BIOS-e820: [mem 0xb867e000-0xbaf7dfff] reserved
> [0.00] BIOS-e820: [mem 0xbaf7e000-0xbcf7dfff] ACPI NVS
> [0.00] BIOS-e820: [mem 0xbcf7e000-0xbcffdfff] ACPI 
> data
> [0.00] BIOS-e820: [mem 0xbcffe000-0xbcffefff] usable
> [0.00] BIOS-e820: [mem 0xbcfff000-0xbfff] reserved
> [0.00] BIOS-e820: [mem 0xf000-0xf3ff] reserved
> [0.00] BIOS-e820: [mem 0xfd00-0xfe7f] reserved
> [0.00] BIOS-e820: [mem 0xfeb0-0xfeb03fff] reserved
> [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
> [0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved
> [0.00] BIOS-e820: [mem 0xfed1-0xfed19fff] reserved
> [0.00] BIOS-e820: [mem 0xfed84000-0xfed84fff] reserved
> [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
> [0.00] BIOS-e820: [mem 0xff90-0x] reserved
> [0.00] BIOS-e820: [mem 0x0001-0x00023dff] usable
> [0.00] NX (Execute Disable) protection: active
> [0.00] extended physical RAM map:
> [0.00] reserve setup_data: [mem 
> 0x-0x000502bf] usable
> [0.00] reserve setup_data: [mem 
> 0x000502c0-0x0005032f] usable
> [0.00] reserve setup_data: [mem 
> 0x00050330-0x00057fff] usable
> [0.00] reserve setup_data: [mem 
> 0x00058000-0x00058fff] reserved
> [0.00] reserve setup_data: [mem 
> 0x00059000-0x00085fff] usable
> [0.00] reserve setup_data: [mem 
> 0x00086000-0x000f] reserved
> [0.00] reserve setup_data: [mem 
>