[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1487211130.3019.7.camel@linux.intel.com>
Date: Thu, 16 Feb 2017 10:12:10 +0800
From: Chao Peng <chao.p.peng@...ux.intel.com>
To: Paolo Bonzini <pbonzini@...hat.com>, linux-kernel@...r.kernel.org,
x86@...nel.org, grub-devel@....org
Cc: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Andy Lutomirski <luto@...nel.org>,
Juergen Gross <jgross@...e.com>,
"Luis R. Rodriguez" <mcgrof@...nel.org>,
Borislav Petkov <bp@...e.de>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Thomas Garnier <thgarnie@...gle.com>,
Al Viro <viro@...iv.linux.org.uk>,
"Michael S. Tsirkin" <mst@...hat.com>,
Amnon Ilan <ailan@...hat.com>
Subject: Re: [RFC PATCH] x86/boot: make ELF kernel multiboot-able
On Wed, 2017-02-15 at 17:42 +0100, Paolo Bonzini wrote:
>
> On 15/02/2017 15:41, Chao Peng wrote:
> >
> > Multiboot specification (http://git.savannah.gnu.org/cgit/grub.git/tree/doc/multiboot.texi?h=mul
> > tiboot2)
> > 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'.
>
> For kvm-unit-tests, we do "objcopy -O elf32-i386 dest.32bit dest.64bit"
> and pass the resulting 32bit ELF file to grub.
>
> Out of curiosity, what happens if you pass the resulting multiboot file
> to QEMU's -kernel option?
>
The resulting kernel is a multiboot2 kernel. QEMU however supports loading
multiboot v1 only.
Chao
> Thanks,
>
> Paolo
>
> >
> > This patch is sent out as RFC in case you have some ideas.
> >
> > Signed-off-by: Chao Peng <chao.p.peng@...ux.intel.com>
Powered by blists - more mailing lists