Re: 3.12 to 3.13 boot regression bisected - still applies to 3.16

[Matt Fleming]

On Tue, 05 Aug, at 02:11:42PM, Bruno Prémont wrote:
> 
> arch/x86/boot/compressed/head_64.S
> 341 /*
> 342  * Copy the compressed kernel to the end of our buffer
> 343  * where decompression in place becomes safe.
> 344  */
> 345         pushq   %rsi
> 346         leaq    (_bss-8)(%rip), %rsi
> 347         leaq    (_bss-8)(%rbx), %rdi
> 348         movq    $_bss /* - $startup_32 */, %rcx
> 349         shrq    $3, %rcx
> 350         std
> 
> code gets up to here
> 
> 351         rep     movsq
> 
> this location is never reached but instead system reboots
> 
> 352         cld
> 353         popq    %rsi
> 354 
> 355 /*      
> 356  * Jump to the relocated address.
> 357  */

Excellent. Thanks for doing this, it's all starting to make sense now.

I suspect if you enable CONFIG_RELOCATABLE things will work just fine.
I've actually got a patch to force that option if CONFIG_EFI_STUB is
enabled to mitigate this exact problem. Could you try it out (see
below)?

Without CONFIG_RELOCATABLE the early boot code will try and decompress
the kernel image to LOAD_PHYSICAL_ADDR. That may have worked in the days
of BIOS, when it was reasonable to assume that nothing important would
be sitting in the 0x10000000 region, but that's just not so for UEFI. 

For UEFI we need to request memory from the firmware and not stray
outside the bounds of those allocations. Otherwise there's the potential
that we'll trash bits of the firmware's code/data.

---