Re: [RFC PATCH] x86/boot: make ELF kernel multiboot-able

["Luis R. Rodriguez" <mcgrof@kernel.org>]

On Wed, Feb 15, 2017 at 10:12:07AM -0800, hpa@zytor.com wrote:
> On February 15, 2017 6:41:56 AM PST, Chao Peng <chao.p.peng@linux.intel.com> wrote:
> >Multiboot specification
> >(http://git.savannah.gnu.org/cgit/grub.git/tree/doc/multiboot.texi?h=multiboot2)
> >is an open standard that provides kernels with a uniform way to be booted
> >by multiboot-compliant bootloaders (like grub).
> >
> >This patch is trying to make Linux ELF kernel image to be a
> >multiboot-compliant OS so that it can be loaded by a multiboot-comliant
> >bootloader. The benefit is eliminating the maintainance for realmode and
> >decompression code and especially when the kernel is loaded in a virtual
> >machine, the reducing for these code can greatly cuts down the boot time.
> >
> >However, the current version of multiboot spec doesn't support 64 bit well
> >so for 64 bit kernel we need stub code to jump from 32 bit code to 64 bit
> >code. Besides, there are still some other issues:
> >
> >1). '-z max-page-size=0x1000' is used so the text segment start is in
> >multiboot header search scope because GNU LD has default page size of
> >0x00200000 for ELF64, which will fail multiboot test.
> >
> >2). The bootloader like grub has support for ELF kernel (even for ELF64)
> >which makes the patch easier. However, the current grub implementaion thinks
> >the entry address should be a VA. E.g. for 64 bit kernel, the entry address
> >(0x1000000) is actually phiscial address, grub refuses to load it by saying:
> >'entry point isn't in a segment'.
> >
> >This patch is sent out as RFC in case you have some ideas.
> >
> >Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
> 
> As has been shown many times before, this is a really bad idea.  Unless there
> is a real-life use case where this matters enormously, this is nacked with
> extreme prejudice.

Just something to consider, provided the issues with multiboot get resolved:

If you want to boot Xen you actually use the multiboot protocol, the last PVH
boot patches had borrowed ideas from Multiboot to add an entry to Linux, only
it was Xen'ified. What would be Multiboot 2 seemed flexible enough to allow all
sorts of custom semantics and information stacked into a boot image. The last
thought I had over this topic (before giving up)  was-- if we're going to add
yet-another-entry (TM) why not add extend Mulitiboot 2 protocol with the
semantics we need to boot any virtual environment and then add Multiboot 2
support entry on Linux? We could redirect any custom boot mechanism then to
just use that given its flexibility.

  Luis