Re: Boot with EFI stub fails on VMWare during decompression

["Bruno Prémont" <bonbons-ud5FBsm0p/xEiooADzr8i9i2O/JbrIOy@public.gmane.org>]

On Tue, 20 Jan 2015 19:02:38 +0000 Matt Fleming wrote:
> On Fri, 16 Jan, at 11:03:44AM, Bruno Prémont wrote:
> > Register dump:
> > rax            0x1000   4096
> > rbx            0x23f78cb        37714123
> > rcx            0x0      0
> > rdx            0x0      0
> > rsi            0x0      0
> > rdi            0x23f7863        37714019
> > rbp            0x1a363b4        0x1a363b4
> > rsp            0x2404b20        0x2404b20
> > r8             0x2404ee0        37768928
> > r9             0x4      4
> > r10            0x3      3
> > r11            0x9      9
> > r12            0x13dcbbc        20827068
> > r13            0x1e000000       503316480      (this seems to point to decompressed kernel)
> 
> [...]
>  
> > while on the failing one I get (just enough efi_printk to cause kernel to boot):
> > [    0.000000] efi: EFI v2.30 by VMware, Inc.
> > [    0.000000] efi:  SMBIOS=0x1ffaf000  ACPI 2.0=0x1ff9f000 
> > [    0.000000] efi: mem00: [ACPI Memory NVS    |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000000000-0x0000000000001000) (0MB)
> 
> [..]
> 
> > [    0.000000] efi: mem23: [Boot Data          |   |  |  |  |   |WB|WT|WC|UC] range=[0x000000001dee8000-0x000000001e547000) (6MB)
> 
> Oops. It sure looks like the EFI boot stub is trashing an EFI boot data
> region. That would certainly explain the memory corruption you're seeing
> (since the firmware assumes no one else is touch its data areas).
> 
> By any chance have you modified CONFIG_PHYSICAL_START in your .config?

As mentioned in the other mail, it's left at default value:
  CONFIG_PHYSICAL_START=0x1000000

> The suspect code is probably this from
> arch/x86/boot/compressed/head_64.S:
> 
> ---
> 
> 	/*
> 	 * Compute the decompressed kernel start address.  It is where
> 	 * we were loaded at aligned to a 2M boundary. %rbp contains the
> 	 * decompressed kernel start address.
> 	 *
> 	 * If it is a relocatable kernel then decompress and run the kernel
> 	 * from load address aligned to 2MB addr, otherwise decompress and
> 	 * run the kernel from LOAD_PHYSICAL_ADDR
> 	 *
> 	 * We cannot rely on the calculation done in 32-bit mode, since we
> 	 * may have been invoked via the 64-bit entry point.
> 	 */
> 
> 	/* Start with the delta to where the kernel will run at. */
> #ifdef CONFIG_RELOCATABLE

I've put a breakpoint here (hlt-loop) and have following details:

(gdb) info registers
rax            0x0      0
rbx            0x1e53ae18       508800536
rcx            0xffffffff       4294967295
rdx            0x1ded8f98       502108056
rsi            0x1000   4096
rdi            0xffffffff       4294967295
rbp            0x1c003e00       0x1c003e00
rsp            0x1ffd7b68       0x1ffd7b68
r8             0x0      0
r9             0x0      0
r10            0x0      0
r11            0x0      0
r12            0x1ffd7dc8       536706504
r13            0x1ffd7dc0       536706496
r14            0x0      0
r15            0x1ffd7dc0       536706496
rip            0x10002ad        0x10002ad
eflags         0x46     [ PF ZF ]
cs             0x18     24
ss             0x0      0
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0
(gdb) disassemble /r 0x10002ac,+64
Dump of assembler code from 0x10002ac to 0x10002ec:
   0x00000000010002ac:  f4      hlt    
=> 0x00000000010002ad:  eb fd   jmp    0x10002ac
   0x00000000010002af:  48 8d 2d 4a fd ff ff    lea    -0x2b6(%rip),%rbp        # 0x1000000
   0x00000000010002b6:  8b 86 30 02 00 00       mov    0x230(%rsi),%eax
   0x00000000010002bc:  ff c8   dec    %eax
   0x00000000010002be:  48 01 c5        add    %rax,%rbp
   0x00000000010002c1:  48 f7 d0        not    %rax
   0x00000000010002c4:  48 21 c5        and    %rax,%rbp
   0x00000000010002c7:  48 81 fd 00 00 00 01    cmp    $0x1000000,%rbp
   0x00000000010002ce:  7d 07   jge    0x10002d7
   0x00000000010002d0:  48 c7 c5 00 00 00 01    mov    $0x1000000,%rbp
   0x00000000010002d7:  48 8d 9d 00 60 a3 00    lea    0xa36000(%rbp),%rbx
   0x00000000010002de:  48 8d a3 00 ec 9c 00    lea    0x9cec00(%rbx),%rsp
   0x00000000010002e5:  6a 00   pushq  $0x0
   0x00000000010002e7:  9d      popfq  
   0x00000000010002e8:  56      push   %rsi
   0x00000000010002e9:  48 8d 35 08 29 9c 00    lea    0x9c2908(%rip),%rsi        # 0x19c2bf8


> 	leaq	startup_32(%rip) /* - $startup_32 */, %rbp
> 	movl	BP_kernel_alignment(%rsi), %eax
> 	decl	%eax
> 	addq	%rax, %rbp
> 	notq	%rax
> 	andq	%rax, %rbp
> 	cmpq	$LOAD_PHYSICAL_ADDR, %rbp
> 	jge	1f
> #endif
> 	movq	$LOAD_PHYSICAL_ADDR, %rbp
> 1:
> 
> You may want to snoop around this code to make sure that we're not
> making some crazy calculation mistakes wrt where we decompress the
> kernel.

So the default LOAD_PHYSICAL_ADDR is being selected/used.

This all happens after efi_main() as far as I can understand.
Is there a way to let efi_printk() do string formatting? It should have
both source and destination addresses as it is doing the relocation (or at
least one step of it).

Bruno