public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: "huang ying" <huang.ying.caritas@gmail.com>
Cc: "Etienne Lorrain" <etienne_lorrain@yahoo.fr>,
	linux-kernel@vger.kernel.org, ebiederm@xmission.com,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH 5/5] x86_64 EFI support -v3: EFI document
Date: Thu, 9 Aug 2007 19:01:10 +0200	[thread overview]
Message-ID: <200708091901.11146.ak@suse.de> (raw)
In-Reply-To: <851fc09e0708090709s4f4fbbf9r91a7300a773f985a@mail.gmail.com>

On Thursday 09 August 2007 16:09:23 huang ying wrote:
> On 8/9/07, Andi Kleen <ak@suse.de> wrote:
> > There is really no 32bit entry point today usable for external users. Or rather
> > it might by chance work today, but if we change the zero page (and there
> > is no guarantee it'll not be changed). I can pretty much guarantee it'll
> > be changed at some point. And you'll break if you use it.
> 
> Yes, there is no official 32bit external entry point. But on EFI
> platform, the 16bit entry point can not be used because there is no
> 16bit BIOS call available. So, I think it is necessary to define a
> 32bit external entry point.

Ok. How do you collect all the data in the zero page then?
There's much more in there than just the memory map.

Anyways for EFI the best way is probably to define a EFI entry
point that does the same work as the real mode code today just
using EFI services.

And for kexec :- well need a proper protocol.

> 
> > kexec can use the 32bit entry, but only because it is in tree so it can be fixed
> > up for any changes.
> 
> The kexec uses the 32bit entry point in a user space tool named
> kexec-tools, not in the kernel.

Ah i didn't realize this. Ok then kexec is also quite broken.
Somehow this must have been missed this fundamental flaw when this code was 
reviewed.

> 
> > If you want to use it you would need to define some versionable protocol
> > first similar to the real mode boot protocol. That would require some work
> > and some thought to make sure it is forwards and backwards compatible.
> 
> I think at least the following should be done to make it a external
> boot protocol.
> 
> 1. A version number field should be added.
> 2. The pointers (especially these come from firmware) should be 64bit
> to make the entry point can be used for both 32bit and 64bit platform.

32bit pointers are not too bad; it needs to be all physical anyways
because kernel virtual mapping can change any time.

> 3. More complete and formal document.
> 
> Can you kindly tell me what's more should be done?

It's a minimum start. But at least for EFI I still think it's better
to just move that code back into the kernel. Just cleanly separated.

-Andi

  parent reply	other threads:[~2007-08-09 17:01 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-09  9:47 [PATCH 5/5] x86_64 EFI support -v3: EFI document Etienne Lorrain
2007-08-09 10:51 ` Andi Kleen
2007-08-09 11:23   ` RE : " Etienne Lorrain
2007-08-09 14:09   ` huang ying
2007-08-09 16:29     ` H. Peter Anvin
2007-08-09 17:01     ` Andi Kleen [this message]
2007-08-09 17:25       ` H. Peter Anvin
2007-08-10 13:03       ` Huang, Ying
  -- strict thread matches above, loose matches on Subject: below --
2007-07-31  3:13 Huang, Ying
2007-07-31  4:40 ` Eric W. Biederman
2007-07-31  6:58   ` Huang, Ying
2007-08-01 17:16     ` Eric W. Biederman
2007-08-07  9:29       ` Huang, Ying
2007-08-07  9:54         ` Andi Kleen
2007-08-08  8:18           ` Huang, Ying
2007-08-08 10:08             ` Andi Kleen
2007-08-08 13:46               ` Huang, Ying
2007-08-08 14:09                 ` Andi Kleen
2007-08-08 15:11                   ` huang ying
2007-08-08 16:23                     ` Andi Kleen
2007-08-08 16:10               ` Eric W. Biederman
2007-08-08 16:22                 ` Andi Kleen
2007-08-08 17:17                   ` Eric W. Biederman

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=200708091901.11146.ak@suse.de \
    --to=ak@suse.de \
    --cc=ebiederm@xmission.com \
    --cc=etienne_lorrain@yahoo.fr \
    --cc=hpa@zytor.com \
    --cc=huang.ying.caritas@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox