public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: "Huang, Ying" <ying.huang@intel.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	akpm@linux-foundation.org, Yinghai Lu <yhlu.kernel@gmail.com>,
	Randy Dunlap <randy.dunlap@oracle.com>,
	Chandramouli Narayanan <mouli@linux.intel.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/5] x86_64 EFI support -v3: EFI document
Date: Tue, 7 Aug 2007 11:54:22 +0200	[thread overview]
Message-ID: <200708071154.23150.ak@suse.de> (raw)
In-Reply-To: <1186478984.3769.46.camel@caritas-dev.intel.com>

On Tuesday 07 August 2007 11:29:44 Huang, Ying wrote:
 
> > How does EFI handle 32bit/64bit compatibility?  In particular
> > how do I load a 32bit kernel on machine with a 64bit EFI?  Can
> > it be done?
> > 
> Because the EFI memory map is converted to E820 map in bootloader now,
> it is possible to load 32bit kernel on machine with a 64bit EFI.

The 32bit EFI code doesn't know this yet, does it?

> But it 
> is almost impossible to call EFI runtime service in 32bit kernel. But I
> think EFI runtime service is not essential in this situation, because
> the raw hardware can be used too.

That doesn't sound good. Is this really supposed to work this way?

If the raw hardware works why are we using EFI services at all? 
We generally trust hardware more than BIOSes.

Might we end up with machines that only boot with the 64bit kernel?

Will systems have a dual EFI implementation? 

Also long term I would like to use a few useful EFI services,
like the support to put some data into the CMOS area to survive
a reboot. That would be quite useful for panics and oopses.
But we would prefer to have that on 32bit too.



-Andi

  reply	other threads:[~2007-08-07  9:54 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-31  3:13 [PATCH 5/5] x86_64 EFI support -v3: EFI document 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 [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
2007-08-09  9:47 Etienne Lorrain
2007-08-09 10:51 ` Andi Kleen
2007-08-09 14:09   ` huang ying
2007-08-09 16:29     ` H. Peter Anvin
2007-08-09 17:01     ` Andi Kleen
2007-08-09 17:25       ` H. Peter Anvin
2007-08-10 13:03       ` Huang, Ying

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=200708071154.23150.ak@suse.de \
    --to=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mouli@linux.intel.com \
    --cc=randy.dunlap@oracle.com \
    --cc=yhlu.kernel@gmail.com \
    --cc=ying.huang@intel.com \
    /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