public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Huang, Ying" <ying.huang@intel.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andi Kleen <ak@suse.de>,
	Chandramouli Narayanan <mouli@linux.intel.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] x86_64 EFI runtime service support
Date: Mon, 20 Aug 2007 13:14:47 +0800	[thread overview]
Message-ID: <1187586887.27947.76.camel@caritas-dev.intel.com> (raw)
In-Reply-To: <m11wdzrwl7.fsf@ebiederm.dsl.xmission.com>

On Sun, 2007-08-19 at 16:25 -0600, Eric W. Biederman wrote:
> "Huang, Ying" <ying.huang@intel.com> writes:
> >> > +#define EFI_LOADER_SIG ((unsigned char *)(PARAM+0x1c0))
> >> > +#define EFI_MEMDESC_SIZE (*((unsigned int *) (PARAM+0x1c4)))
> >> > +#define EFI_MEMDESC_VERSION (*((unsigned int *) (PARAM+0x1c8)))
> >> > +#define EFI_MEMMAP_SIZE (*((unsigned int *) (PARAM+0x1cc)))
> >> > +#define EFI_MEMMAP (*((unsigned long *)(PARAM+0x1d0)))
> >> > +#define EFI_SYSTAB (*((unsigned long *)(PARAM+0x1d8)))
> >> >  #define MOUNT_ROOT_RDONLY (*(unsigned short *) (PARAM+0x1F2))
> Be very very very  careful how you talk about this.
> 
> I have seen machines in the wild a 64bit processor and a 32bit EFI.
> So this is not a linux architecture issue, or a cpu architecture
> issue.  This is an EFI architecture issue.
> 
> This is an issue of do you have a 32bit or a 64bit EFI implementation
> on your machine.  Which is very different.
> 
> We should be able to boot a 32bit kernel with a 64bit EFI.
> We should be able to boot a 64bit kernel with a 32bit EFI.
> 
> Maybe our response is to ignore the information from elilo so
> we don't attempt EFI runtime calls but the boot information should
> be unambiguous.
> 
> So we need to be able to look at the data and answer these questions.
> - Is EFI present?
> - Is EFI 32bit?
> - Is EFI 64bit?

Yes, it is necessary to distinguish these situations. I think the
EFI_LOADER_SIG defined above can be used for that. For example the
following signature can be defined:

32-bit EFI	EL32
64-bit EFI	EL64

All other values will be treated as no EFI present.

If struct setup_data proposed by H. Peter Anvin is used for EFI
information passed from bootloader, two "type" can be defined for 32-bit
EFI and 64-bit EFI, such as SETUP_DATA_TYPE_EFI_32 and
SETUP_DATA_TYPE_EFI64. If either type is not presented in "linked list
of struct setup_data", it is considered that EFI is not present.

Best Regards,
Huang Ying

  parent reply	other threads:[~2007-08-20  5:14 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-13  7:30 [PATCH 0/3] x86_64 EFI runtime service support Huang, Ying
2007-08-15 22:42 ` Andrew Morton
2007-08-16  7:51   ` Huang, Ying
2007-08-16 14:11     ` Andi Kleen
2007-08-17  1:25       ` Huang, Ying
2007-08-17 16:11         ` H. Peter Anvin
2007-08-20  3:20           ` Huang, Ying
2007-08-20 17:12             ` H. Peter Anvin
2007-08-21  1:44               ` Huang, Ying
2007-08-21  3:54                 ` H. Peter Anvin
2007-08-21  4:53                   ` Huang, Ying
2007-08-21 11:33               ` Andi Kleen
2007-08-21 10:41                 ` H. Peter Anvin
2007-08-21 11:45                   ` Andi Kleen
2007-08-21 23:58                     ` Yinghai Lu
2007-08-22  1:22                       ` Andi Kleen
2007-08-22  6:43                         ` Yinghai Lu
2007-08-22 11:11                           ` Andi Kleen
2007-08-22 14:23                             ` huang ying
2007-08-22 16:28                               ` H. Peter Anvin
2007-08-23  2:21                                 ` Huang, Ying
2007-08-23  2:46                                   ` H. Peter Anvin
2007-08-22 14:41                             ` Eric W. Biederman
2007-08-22 16:44                               ` H. Peter Anvin
2007-08-22  7:20                         ` Yinghai Lu
2007-08-15 23:16 ` Andrew Morton
2007-08-15 23:22   ` H. Peter Anvin
2007-08-16  8:00     ` Huang, Ying
2007-08-16 16:09       ` H. Peter Anvin
2007-08-19 22:27         ` Eric W. Biederman
2007-08-19 22:25       ` Eric W. Biederman
2007-08-19 23:46         ` Yinghai Lu
2007-08-20 17:05           ` H. Peter Anvin
2007-08-20 17:20             ` San Mehat
2007-08-20 20:13             ` Matthew Garrett
2007-08-20  5:14         ` Huang, Ying [this message]
2007-08-16  7:52   ` 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=1187586887.27947.76.camel@caritas-dev.intel.com \
    --to=ying.huang@intel.com \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mouli@linux.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