All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.