Jeremy Fitzhardinge wrote:
> OK, here's another go-around. This patch leaves the bzImage itself
> unmodified, but it changes the payload into an ELF file. That is, the
> 32-bit decompression/relocation+compressed kernel is now a properly
> formed ELF file.
>
> One thing that fell out of this is that code32_start end up being a
> pointer to the ELF header rather than an entrypoint. Rather than
> reproducing Vivek's (?) hack of making the ELF header itself executable,
> I changed the 16-bit code to check for an ELF magic number at
> code32_start and use the e_entry to get the actual entrypoint. This
> seems like approximately the right way of doing this, but I'm not sure
> how we want to formalize it. It's certainly easier than trying to
> extract the payload's entry address and copying it to code32_start in
> the boot_params block, and we need a pointer to the ELF file itself anyway.
>
No, that breaks any boot loader that uses the boot loader hook
mechanism. That's definitely broken.
Either way, I still believe that this should be done at the other end of
the decompression chain. Give out the information about *how the kernel
will be executed*, not about the intermediate, transient step.
-hpa
_______________________________________________
Virtualization mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/virtualization
