public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Huang, Ying" <ying.huang@intel.com>
To: Paul Jackson <pj@sgi.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Jack Steiner <steiner@sgi.com>, Mike Travis <travis@sgi.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org, Andi Kleen <andi@firstfloor.org>,
	Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH 10/10] x86 boot: add code to add BIOS provided EFI memory entries to kernel
Date: Tue, 27 May 2008 11:12:28 +0800	[thread overview]
Message-ID: <1211857948.12819.84.camel@caritas-dev.intel.com> (raw)
In-Reply-To: <20080514151558.148486.91282.sendpatchset@jackhammer.engr.sgi.com>

Hi, Paul,

Sorry for my late. I am busy on something other these days.

Because EFI memory map are converted to E820 memory map in boot loader
if the converted E820 entry number is below 128 now, I think it is
better to do all the conversion in boot loader. The limitation lies in
the size of struct boot_params (zero page), which is 4k. But there is an
extension to struct boot_params named linked list of struct setup_data
in a previous patch:

http://lkml.org/lkml/2008/3/27/26

With the help of linked list of struct setup_data, the E820 memory map
with more than 128 entries in EFI system can be passed to kernel as
follow.

1. In boot loader, EFI memory map is converted to E820 memory map A
2. The low 128 map entries of map A is copied to e820_map of struct
boot_params.
3. A setup_data struct is constructed to hold the other E820 entries.

4. In Linux kernel, the E820 map entries from both struct boot_params
and setup_data are used.

Best Regards,
Huang Ying

On Wed, 2008-05-14 at 08:15 -0700, Paul Jackson wrote:
> From: Paul Jackson <pj@sgi.com>
> 
> Add to the kernels boot memory map 'memmap' entries found in
> the EFI memory descriptors passed in from the BIOS.
> 
> On EFI systems, up to E820MAX == 128 memory map entries can
> be passed via the legacy E820 interface (limited by the size
> of the 'zeropage').  These entries can be duplicated in the
> EFI descriptors also passed from the BIOS, and possibly more
> entries passed by the EFI interface, which does not have the
> E820MAX limit on number of memory map entries.
> 
> This code doesn't worry about the likely duplicate, overlapping
> or (unlikely) conflicting entries between the EFI map and the
> E820 map.  It just dumps all the EFI entries into the memmap[]
> array (which already has the E820 entries) and lets the existing
> routine sanitize_e820_map() sort the mess out.
> 
> Signed-off-by: Paul Jackson <pj@sgi.com>
> 
> ---
>  arch/x86/kernel/efi.c |   26 ++++++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
> 
> --- linux.orig/arch/x86/kernel/efi.c	2008-05-06 06:44:32.332774433 -0700
> +++ linux/arch/x86/kernel/efi.c	2008-05-06 06:55:20.767816417 -0700
> @@ -213,6 +213,31 @@ unsigned long efi_get_time(void)
>  		      eft.minute, eft.second);
>  }
>  
> +/*
> + * Tell the kernel about the EFI memory map.  This might include
> + * more than the max 128 entries that can fit in the e820 legacy
> + * (zeropage) memory map.
> + */
> +
> +static void __init add_efi_memmap(void)
> +{
> +	void *p;
> +
> +	for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
> +		efi_memory_desc_t *md = p;
> +		unsigned long long start = md->phys_addr;
> +		unsigned long long size = md->num_pages << EFI_PAGE_SHIFT;
> +		int e820_type;
> +
> +		if (md->attribute & EFI_MEMORY_WB)
> +			e820_type = E820_RAM;
> +		else
> +			e820_type = E820_RESERVED;
> +		add_memory_region(start, size, e820_type);
> +	}
> +	sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map);
> +}
> +
>  #if EFI_DEBUG
>  static void __init print_efi_memmap(void)
>  {
> @@ -370,6 +395,7 @@ void __init efi_init(void)
>  	if (memmap.desc_size != sizeof(efi_memory_desc_t))
>  		printk(KERN_WARNING "Kernel-defined memdesc"
>  		       "doesn't match the one from EFI!\n");
> +	add_efi_memmap();
>  
>  	/* Setup for EFI runtime service */
>  	reboot_type = BOOT_EFI;
> 

  parent reply	other threads:[~2008-05-27  3:11 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-14 15:15 [PATCH 1/10] x86 boot: include missing smp.h header Paul Jackson
2008-05-14 15:15 ` [PATCH 2/10] x86 boot: remove some unused extern function declarations Paul Jackson
2008-05-14 15:15 ` [PATCH 3/10] x86 boot: add header comment to dmi.h stating what it is Paul Jackson
2008-05-14 15:15 ` [PATCH 4/10] x86 boot: simplify pageblock_bits enum declaration Paul Jackson
2008-05-14 15:15 ` [PATCH 5/10] x86 boot: minor code format fixes in e820 and efi routines Paul Jackson
2008-05-14 15:15 ` [PATCH 6/10] x86 boot: proper use of ARRAY_SIZE instead of repeated E820MAX constant Paul Jackson
2008-05-14 15:15 ` [PATCH 7/10] x86 boot: extend some internal memory map arrays to handle larger EFI input Paul Jackson
2008-05-14 15:15 ` [PATCH 8/10] x86 boot: change sanitize_e820_map parameter from byte to int to allow bigger memory maps Paul Jackson
2008-05-14 15:15 ` [PATCH 9/10] x86 boot: longer comment explaining sanitize_e820_map routine Paul Jackson
2008-05-14 15:15 ` [PATCH 10/10] x86 boot: add code to add BIOS provided EFI memory entries to kernel Paul Jackson
2008-05-16  0:03   ` Paul Jackson
2008-05-16 12:38     ` Ingo Molnar
2008-05-16 16:30       ` Paul Jackson
2008-05-18  6:49       ` Paul Jackson
2008-05-19 16:10         ` Ingo Molnar
2008-05-27  3:12   ` Huang, Ying [this message]
2008-05-27 19:08     ` Paul Jackson
2008-05-27 19:16       ` H. Peter Anvin
2008-05-28  9:59         ` Paul Jackson
2008-05-16 13:20 ` [PATCH 1/10] x86 boot: include missing smp.h header Mike Travis

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=1211857948.12819.84.camel@caritas-dev.intel.com \
    --to=ying.huang@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=pj@sgi.com \
    --cc=steiner@sgi.com \
    --cc=tglx@linutronix.de \
    --cc=travis@sgi.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