LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@in.ibm.com>
To: Etienne Lorrain <etienne_lorrain@yahoo.fr>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org,
	"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: Re : Re : [PATCH] Compressed ia32 ELF file generation for loading by Gujin 1/3
Date: Thu, 8 Feb 2007 10:15:25 +0530	[thread overview]
Message-ID: <20070208044525.GA5997@in.ibm.com> (raw)
In-Reply-To: <848486.58910.qm@web26907.mail.ukl.yahoo.com>

On Wed, Feb 07, 2007 at 02:55:39PM +0000, Etienne Lorrain wrote:
> Vivek Goyal wrote:
> >How do I know which program header is real mode code and the boot loader
> > is not supposed to load it? May be PT_LOAD header with physical addr 0?
> > What happens if changes happen and down the line we start compiling 
> > real mode code for non-zero address?
> 
>  Yes, any PT_LOAD below 64 Kbytes can only be real mode, and real-mode
> cannot be loaded higher, and cannot be bigger than 640 Kbytes, anything
> different (like with virtual address at 0xC0000000) is Linux protected mode.
> Considering the linker used it is always the 4th program header, before there
> were only 3 program header,third one stay the NOTE one.
> 

Well this is all a lot of speculation. This is not standard way of retrieving
information from ELF. Number of program headers finally created keep on
changing. Previously it was left to the linker and now people have changed
it to 3 by specifically using PHDR directive.
  
> > Hence I think keeping real mode code out of vmlinux might prove to be a good idea.
> 
>  Well, ELF is a format made to describe what to load, at which addres, and I assume
> everyone recognise that some ELF section shall not be loaded, like the debug information.
> Gujin accepts having the real-mode treated like a program text and so in the program header,
> or like extra memory block with content like the symbol table used by a debugger, I do not
> know what is best so have implemented the two.
> 
> > Secondly, if you compile real mode code with vmlinux, what would be the
> > entry point for this ELF file? Real mode entry? Then I have not way to
> > find out from ELF headers where is the protected mode entry point and
> > I can not do use this vmlinux with kexec/kdump.
> 
>  I did not touch the kernel entry point, the real mode entry point is at offset zero
> in the real-mode program header/section table.
> 
> > OTOH, now bzImage is relocatable. Is this image going to be relocatable?
> > How do we take care of that?
> 
>  Just I did not completely understand why you need relocation (and the announce
> was when I was in holidays far away). I know a simple kernel is needed to do
> some debugging when the main kernel has crashed, this kernel is better loaded
> at for instance 16 Mbytes. You probably do not want the same kernel as the main
> one because it may crash the same way, and you start a loop - and even then
> if you have exactly the same kernel it is easier to use the same write-protected
> block of memory with different data sections.
>  But I probably do not understand the problem so do not know what to write.
> 

As long as one can make sure that test kernel boots (commonly the case with
distros), same kernel can be used as capture kernel too. So the idea here
is to be able to use same kernel binary as production kernel and capture
kernel hence distros don't have to ship an additional kernel binary compiled
for a different physical addr just for dump capturing purposes.

Currently relocation information is extracted from vmlinux and packed in
final bzImage after some processing. After execution of real mode code
and once the image is decompressed, all the relocations are performed and
then control is transferred to kernel.

Thanks
Vivek

  reply	other threads:[~2007-02-08  4:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-07 14:55 Etienne Lorrain
2007-02-08  4:45 ` Vivek Goyal [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-02-06 18:39 Etienne Lorrain
2007-02-06 18:57 ` Eric W. Biederman
2007-02-06 17:59 Etienne Lorrain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070208044525.GA5997@in.ibm.com \
    --to=vgoyal@in.ibm.com \
    --cc=ebiederm@xmission.com \
    --cc=etienne_lorrain@yahoo.fr \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: Re : Re : [PATCH] Compressed ia32 ELF file generation for loading by Gujin 1/3' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).