mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Cliff Wickman <cpw@sgi.com>
To: linux-kernel@vger.kernel.org
Cc: mingo@elte.hu, hpa@zytor.com
Subject: [PATCH] x86: vendor reserved memory type
Date: Thu, 11 Jun 2009 09:27:27 -0500	[thread overview]
Message-ID: <E1MElFX-0007fY-TR@eag09.americas.sgi.com> (raw)

From: Cliff Wickman <cpw@sgi.com>

Create a new e820 memory type (E820_VENDOR_RESERVED) for areas
of memory reserved by the BIOS in the EFI table.

(An example use of this functionality is the UV system, which
 will access extremely large areas of memory with a memory engine
 that allows a user to address beyond the processor's range.  Such
 areas are reserved in the EFI table by the BIOS.)

Without this patch the EFI_RESERVED_TYPE memory reservations will be
marked usable in the e820 table. There will be a collision between
kernel use and reserver's use of this memory.

This patch causes the EFI_RESERVED_TYPE memory reservations to be recorded
in the e820 table as new type E820_VENDOR_RESERVED.
This patch makes sanitize_e820_map() preserve E820_VENDOR_RESERVED types
as separate entries.

[The elilo loader may combine regions of like type as it builds the e820
 table in boot_params (regular RAM and vendor reserved areas are combined).
 But this patch makes do_add_efi_memmap() separate the RESERVED regions
 into separate e820 entries.
 Some loaders have a restricted number of entries possible in the e820 table,
 hence the need to record the reservations in the unrestricted EFI table.]
The call to do_add_efi_memmap() is only made if "add_efi_memmap" is specified
on the kernel command line.

Diffed against 2.6.30-rc8

Signed-off-by: Cliff Wickman <cpw@sgi.com>

---
 arch/x86/include/asm/e820.h |    1 +
 arch/x86/kernel/e820.c      |    7 ++++++-
 arch/x86/kernel/efi.c       |    4 +++-
 3 files changed, 10 insertions(+), 2 deletions(-)

Index: linux/arch/x86/kernel/e820.c
===================================================================
--- linux.orig/arch/x86/kernel/e820.c
+++ linux/arch/x86/kernel/e820.c
@@ -141,6 +141,9 @@ static void __init e820_print_type(u32 t
 	case E820_RESERVED:
 		printk(KERN_CONT "(reserved)");
 		break;
+	case E820_VENDOR_RESERVED:
+		printk(KERN_CONT "(vendor reserved)");
+		break;
 	case E820_ACPI:
 		printk(KERN_CONT "(ACPI data)");
 		break;
@@ -355,8 +358,10 @@ int __init sanitize_e820_map(struct e820
 		/*
 		 * continue building up new bios map based on this
 		 * information
+		 * (do not consolidate the E820_VENDOR_RESERVED ranges)
 		 */
-		if (current_type != last_type)	{
+		if ((current_type != last_type) ||
+		    (current_type == E820_VENDOR_RESERVED)) {
 			if (last_type != 0)	 {
 				new_bios[new_bios_entry].size =
 					change_point[chgidx]->addr - last_addr;
Index: linux/arch/x86/kernel/efi.c
===================================================================
--- linux.orig/arch/x86/kernel/efi.c
+++ linux/arch/x86/kernel/efi.c
@@ -240,7 +240,9 @@ static void __init do_add_efi_memmap(voi
 		unsigned long long size = md->num_pages << EFI_PAGE_SHIFT;
 		int e820_type;
 
-		if (md->attribute & EFI_MEMORY_WB)
+		if (md->type == EFI_RESERVED_TYPE)
+			e820_type = E820_VENDOR_RESERVED;
+		else if (md->attribute & EFI_MEMORY_WB)
 			e820_type = E820_RAM;
 		else
 			e820_type = E820_RESERVED;
Index: linux/arch/x86/include/asm/e820.h
===================================================================
--- linux.orig/arch/x86/include/asm/e820.h
+++ linux/arch/x86/include/asm/e820.h
@@ -44,6 +44,7 @@
 #define E820_ACPI	3
 #define E820_NVS	4
 #define E820_UNUSABLE	5
+#define E820_VENDOR_RESERVED 6
 
 /* reserved RAM used by kernel itself */
 #define E820_RESERVED_KERN        128

             reply	other threads:[~2009-06-11 14:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-11 14:27 Cliff Wickman [this message]
2009-06-11 15:34 ` H. Peter Anvin
2009-06-12 13:39   ` Cliff Wickman
2009-06-12 18:01     ` H. Peter Anvin
2009-06-12 18:17       ` Yinghai Lu
2009-06-12 18:20         ` H. Peter Anvin

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=E1MElFX-0007fY-TR@eag09.americas.sgi.com \
    --to=cpw@sgi.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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

all inboxes | Powered by JetHome®