2008-05-11 07:30:15 +00:00
|
|
|
/*
|
2017-01-28 10:13:08 +00:00
|
|
|
* Low level x86 E820 memory map handling functions.
|
2008-05-11 07:30:15 +00:00
|
|
|
*
|
2017-01-28 10:13:08 +00:00
|
|
|
* The firmware and bootloader passes us the "E820 table", which is the primary
|
|
|
|
* physical memory layout description available about x86 systems.
|
2008-05-11 07:30:15 +00:00
|
|
|
*
|
2017-01-28 10:13:08 +00:00
|
|
|
* The kernel takes the E820 memory layout and optionally modifies it with
|
|
|
|
* quirks and other tweaks, and feeds that into the generic Linux memory
|
|
|
|
* allocation code routines via a platform independent interface (memblock, etc.).
|
2008-05-11 07:30:15 +00:00
|
|
|
*/
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/types.h>
|
|
|
|
#include <linux/init.h>
|
2011-03-23 23:43:29 +00:00
|
|
|
#include <linux/crash_dump.h>
|
2011-05-26 16:22:53 +00:00
|
|
|
#include <linux/export.h>
|
2008-05-11 07:30:15 +00:00
|
|
|
#include <linux/bootmem.h>
|
|
|
|
#include <linux/pfn.h>
|
2008-05-21 03:10:58 +00:00
|
|
|
#include <linux/suspend.h>
|
2011-01-07 00:43:44 +00:00
|
|
|
#include <linux/acpi.h>
|
2008-06-27 11:12:55 +00:00
|
|
|
#include <linux/firmware-map.h>
|
2010-08-25 20:39:17 +00:00
|
|
|
#include <linux/memblock.h>
|
2011-11-15 22:46:50 +00:00
|
|
|
#include <linux/sort.h>
|
2008-05-11 07:30:15 +00:00
|
|
|
|
2017-01-27 09:27:10 +00:00
|
|
|
#include <asm/e820/api.h>
|
2008-05-18 08:18:57 +00:00
|
|
|
#include <asm/proto.h>
|
2008-05-11 07:30:15 +00:00
|
|
|
#include <asm/setup.h>
|
2016-01-26 21:12:04 +00:00
|
|
|
#include <asm/cpufeature.h>
|
2008-05-11 07:30:15 +00:00
|
|
|
|
2008-06-27 11:12:55 +00:00
|
|
|
/*
|
2017-01-28 09:07:49 +00:00
|
|
|
* We organize the E820 table into two main data structures:
|
|
|
|
*
|
|
|
|
* - 'e820_table_firmware': the original firmware version passed to us by the
|
|
|
|
* bootloader - not modified by the kernel. We use this to:
|
|
|
|
*
|
|
|
|
* - inform the user about the firmware's notion of memory layout
|
|
|
|
* via /sys/firmware/memmap
|
|
|
|
*
|
|
|
|
* - the hibernation code uses it to generate a kernel-independent MD5
|
|
|
|
* fingerprint of the physical memory layout of a system.
|
|
|
|
*
|
2017-01-28 10:13:08 +00:00
|
|
|
* - kexec, which is a bootloader in disguise, uses the original E820
|
2017-01-28 09:07:49 +00:00
|
|
|
* layout to pass to the kexec-ed kernel. This way the original kernel
|
2017-01-28 10:13:08 +00:00
|
|
|
* can have a restricted E820 map while the kexec()-ed kexec-kernel
|
2017-01-28 09:07:49 +00:00
|
|
|
* can have access to full memory - etc.
|
|
|
|
*
|
2017-01-28 10:13:08 +00:00
|
|
|
* - 'e820_table': this is the main E820 table that is massaged by the
|
2017-01-28 09:07:49 +00:00
|
|
|
* low level x86 platform code, or modified by boot parameters, before
|
|
|
|
* passed on to higher level MM layers.
|
|
|
|
*
|
2017-01-28 10:13:08 +00:00
|
|
|
* Once the E820 map has been converted to the standard Linux memory layout
|
2017-01-28 09:07:49 +00:00
|
|
|
* information its role stops - modifying it has no effect and does not get
|
|
|
|
* re-propagated. So itsmain role is a temporary bootstrap storage of firmware
|
|
|
|
* specific memory layout data during early bootup.
|
2008-06-27 11:12:55 +00:00
|
|
|
*/
|
2017-01-28 09:07:49 +00:00
|
|
|
static struct e820_table e820_table_init __initdata;
|
|
|
|
static struct e820_table e820_table_firmware_init __initdata;
|
|
|
|
|
|
|
|
struct e820_table *e820_table __refdata = &e820_table_init;
|
|
|
|
struct e820_table *e820_table_firmware __refdata = &e820_table_firmware_init;
|
2008-05-11 07:30:15 +00:00
|
|
|
|
|
|
|
/* For PCI or other memory-mapped resources */
|
|
|
|
unsigned long pci_mem_start = 0xaeedbabe;
|
|
|
|
#ifdef CONFIG_PCI
|
|
|
|
EXPORT_SYMBOL(pci_mem_start);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This function checks if any part of the range <start,end> is mapped
|
|
|
|
* with type.
|
|
|
|
*/
|
2017-01-28 13:14:25 +00:00
|
|
|
int e820__mapped_any(u64 start, u64 end, unsigned type)
|
2008-05-11 07:30:15 +00:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2017-01-27 13:06:21 +00:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
2017-01-28 11:16:17 +00:00
|
|
|
struct e820_entry *entry = &e820_table->entries[i];
|
2008-05-11 07:30:15 +00:00
|
|
|
|
2017-01-28 11:16:17 +00:00
|
|
|
if (type && entry->type != type)
|
2008-05-11 07:30:15 +00:00
|
|
|
continue;
|
2017-01-28 11:16:17 +00:00
|
|
|
if (entry->addr >= end || entry->addr + entry->size <= start)
|
2008-05-11 07:30:15 +00:00
|
|
|
continue;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
2017-01-28 13:14:25 +00:00
|
|
|
EXPORT_SYMBOL_GPL(e820__mapped_any);
|
2008-05-11 07:30:15 +00:00
|
|
|
|
|
|
|
/*
|
2017-01-28 10:13:08 +00:00
|
|
|
* This function checks if the entire <start,end> range is mapped with 'type'.
|
2008-05-11 07:30:15 +00:00
|
|
|
*
|
2017-01-28 10:13:08 +00:00
|
|
|
* Note: this function only works correctly once the E820 table is sorted and
|
|
|
|
* not-overlapping (at least for the range specified), which is the case normally.
|
2008-05-11 07:30:15 +00:00
|
|
|
*/
|
2017-01-28 13:14:25 +00:00
|
|
|
int __init e820__mapped_all(u64 start, u64 end, unsigned type)
|
2008-05-11 07:30:15 +00:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2017-01-27 13:06:21 +00:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
2017-01-28 11:16:17 +00:00
|
|
|
struct e820_entry *entry = &e820_table->entries[i];
|
2008-05-11 07:30:15 +00:00
|
|
|
|
2017-01-28 11:16:17 +00:00
|
|
|
if (type && entry->type != type)
|
2008-05-11 07:30:15 +00:00
|
|
|
continue;
|
2017-01-28 10:13:08 +00:00
|
|
|
|
|
|
|
/* Is the region (part) in overlap with the current region? */
|
2017-01-28 11:16:17 +00:00
|
|
|
if (entry->addr >= end || entry->addr + entry->size <= start)
|
2008-05-11 07:30:15 +00:00
|
|
|
continue;
|
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/*
|
|
|
|
* If the region is at the beginning of <start,end> we move
|
|
|
|
* 'start' to the end of the region since it's ok until there
|
2008-05-11 07:30:15 +00:00
|
|
|
*/
|
2017-01-28 11:16:17 +00:00
|
|
|
if (entry->addr <= start)
|
|
|
|
start = entry->addr + entry->size;
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2008-05-11 07:30:15 +00:00
|
|
|
/*
|
2017-01-28 10:13:08 +00:00
|
|
|
* If 'start' is now at or beyond 'end', we're done, full
|
|
|
|
* coverage of the desired range exists:
|
2008-05-11 07:30:15 +00:00
|
|
|
*/
|
|
|
|
if (start >= end)
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2017-01-28 10:13:08 +00:00
|
|
|
* Add a memory region to the kernel E820 map.
|
2008-05-11 07:30:15 +00:00
|
|
|
*/
|
x86/boot/e820: Create coherent API function names for E820 range operations
We have these three related functions:
extern void e820_add_region(u64 start, u64 size, int type);
extern u64 e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);
But it's not clear from the naming that they are 3 operations based around the
same 'memory range' concept. Rename them to better signal this, and move
the prototypes next to each other:
extern void e820__range_add (u64 start, u64 size, int type);
extern u64 e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);
Note that this improved organization of the functions shows another problem that was easy
to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
will be fixed in a separate patch.
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 13:19:36 +00:00
|
|
|
static void __init __e820__range_add(struct e820_table *table, u64 start, u64 size, int type)
|
2008-05-11 07:30:15 +00:00
|
|
|
{
|
2017-01-27 13:06:21 +00:00
|
|
|
int x = table->nr_entries;
|
2008-05-11 07:30:15 +00:00
|
|
|
|
2017-01-27 13:06:21 +00:00
|
|
|
if (x >= ARRAY_SIZE(table->entries)) {
|
2017-01-28 11:27:45 +00:00
|
|
|
pr_err("e820: too many entries; ignoring [mem %#010llx-%#010llx]\n", start, start + size - 1);
|
2008-05-11 07:30:15 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2017-01-27 13:06:21 +00:00
|
|
|
table->entries[x].addr = start;
|
|
|
|
table->entries[x].size = size;
|
|
|
|
table->entries[x].type = type;
|
|
|
|
table->nr_entries++;
|
2009-03-13 04:35:18 +00:00
|
|
|
}
|
|
|
|
|
x86/boot/e820: Create coherent API function names for E820 range operations
We have these three related functions:
extern void e820_add_region(u64 start, u64 size, int type);
extern u64 e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);
But it's not clear from the naming that they are 3 operations based around the
same 'memory range' concept. Rename them to better signal this, and move
the prototypes next to each other:
extern void e820__range_add (u64 start, u64 size, int type);
extern u64 e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);
Note that this improved organization of the functions shows another problem that was easy
to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
will be fixed in a separate patch.
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 13:19:36 +00:00
|
|
|
void __init e820__range_add(u64 start, u64 size, int type)
|
2009-03-13 04:35:18 +00:00
|
|
|
{
|
x86/boot/e820: Create coherent API function names for E820 range operations
We have these three related functions:
extern void e820_add_region(u64 start, u64 size, int type);
extern u64 e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);
But it's not clear from the naming that they are 3 operations based around the
same 'memory range' concept. Rename them to better signal this, and move
the prototypes next to each other:
extern void e820__range_add (u64 start, u64 size, int type);
extern u64 e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);
Note that this improved organization of the functions shows another problem that was easy
to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
will be fixed in a separate patch.
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 13:19:36 +00:00
|
|
|
__e820__range_add(e820_table, start, size, type);
|
2008-05-11 07:30:15 +00:00
|
|
|
}
|
|
|
|
|
2009-03-15 07:59:19 +00:00
|
|
|
static void __init e820_print_type(u32 type)
|
|
|
|
{
|
|
|
|
switch (type) {
|
2017-01-28 10:13:08 +00:00
|
|
|
case E820_RAM: /* Fall through: */
|
2017-01-28 11:27:45 +00:00
|
|
|
case E820_RESERVED_KERN: pr_cont("usable"); break;
|
|
|
|
case E820_RESERVED: pr_cont("reserved"); break;
|
|
|
|
case E820_ACPI: pr_cont("ACPI data"); break;
|
|
|
|
case E820_NVS: pr_cont("ACPI NVS"); break;
|
|
|
|
case E820_UNUSABLE: pr_cont("unusable"); break;
|
2017-01-28 10:13:08 +00:00
|
|
|
case E820_PMEM: /* Fall through: */
|
2017-01-28 11:27:45 +00:00
|
|
|
case E820_PRAM: pr_cont("persistent (type %u)", type); break;
|
|
|
|
default: pr_cont("type %u", type); break;
|
2009-03-15 07:59:19 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-01-28 13:24:02 +00:00
|
|
|
void __init e820__print_table(char *who)
|
2008-05-11 07:30:15 +00:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2017-01-27 13:06:21 +00:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
2017-01-28 11:27:45 +00:00
|
|
|
pr_info("%s: [mem %#018Lx-%#018Lx] ", who,
|
2017-01-28 10:13:08 +00:00
|
|
|
e820_table->entries[i].addr,
|
|
|
|
e820_table->entries[i].addr + e820_table->entries[i].size - 1);
|
|
|
|
|
2017-01-27 13:06:21 +00:00
|
|
|
e820_print_type(e820_table->entries[i].type);
|
2017-01-28 11:27:45 +00:00
|
|
|
pr_cont("\n");
|
2008-05-11 07:30:15 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2017-01-28 10:13:08 +00:00
|
|
|
* Sanitize the BIOS E820 map.
|
2008-05-11 07:30:15 +00:00
|
|
|
*
|
2017-01-28 10:13:08 +00:00
|
|
|
* Some E820 responses include overlapping entries. The following
|
|
|
|
* replaces the original E820 map with a new one, removing overlaps,
|
2008-05-14 15:15:52 +00:00
|
|
|
* and resolving conflicting memory types in favor of highest
|
|
|
|
* numbered type.
|
2008-05-11 07:30:15 +00:00
|
|
|
*
|
2008-05-14 15:15:52 +00:00
|
|
|
* The input parameter biosmap points to an array of 'struct
|
2017-01-27 11:54:38 +00:00
|
|
|
* e820_entry' which on entry has elements in the range [0, *pnr_map)
|
2008-05-14 15:15:52 +00:00
|
|
|
* valid, and which has space for up to max_nr_map entries.
|
2017-01-28 10:13:08 +00:00
|
|
|
* On return, the resulting sanitized E820 map entries will be in
|
2008-05-14 15:15:52 +00:00
|
|
|
* overwritten in the same location, starting at biosmap.
|
|
|
|
*
|
|
|
|
* The integer pointed to by pnr_map must be valid on entry (the
|
2015-01-07 03:37:38 +00:00
|
|
|
* current number of valid entries located at biosmap). If the
|
|
|
|
* sanitizing succeeds the *pnr_map will be updated with the new
|
|
|
|
* number of valid entries (something no more than max_nr_map).
|
2008-05-14 15:15:52 +00:00
|
|
|
*
|
2017-01-28 13:09:20 +00:00
|
|
|
* The return value from e820__update_table() is zero if it
|
2008-05-14 15:15:52 +00:00
|
|
|
* successfully 'sanitized' the map entries passed in, and is -1
|
|
|
|
* if it did nothing, which can happen if either of (1) it was
|
|
|
|
* only passed one map entry, or (2) any of the input map entries
|
|
|
|
* were invalid (start + size < start, meaning that the size was
|
|
|
|
* so big the described memory range wrapped around through zero.)
|
|
|
|
*
|
|
|
|
* Visually we're performing the following
|
|
|
|
* (1,2,3,4 = memory types)...
|
|
|
|
*
|
|
|
|
* Sample memory map (w/overlaps):
|
|
|
|
* ____22__________________
|
|
|
|
* ______________________4_
|
|
|
|
* ____1111________________
|
|
|
|
* _44_____________________
|
|
|
|
* 11111111________________
|
|
|
|
* ____________________33__
|
|
|
|
* ___________44___________
|
|
|
|
* __________33333_________
|
|
|
|
* ______________22________
|
|
|
|
* ___________________2222_
|
|
|
|
* _________111111111______
|
|
|
|
* _____________________11_
|
|
|
|
* _________________4______
|
|
|
|
*
|
|
|
|
* Sanitized equivalent (no overlap):
|
|
|
|
* 1_______________________
|
|
|
|
* _44_____________________
|
|
|
|
* ___1____________________
|
|
|
|
* ____22__________________
|
|
|
|
* ______11________________
|
|
|
|
* _________1______________
|
|
|
|
* __________3_____________
|
|
|
|
* ___________44___________
|
|
|
|
* _____________33_________
|
|
|
|
* _______________2________
|
|
|
|
* ________________1_______
|
|
|
|
* _________________4______
|
|
|
|
* ___________________2____
|
|
|
|
* ____________________33__
|
|
|
|
* ______________________4_
|
2008-05-11 07:30:15 +00:00
|
|
|
*/
|
2011-11-15 22:46:50 +00:00
|
|
|
struct change_member {
|
2017-01-28 10:13:08 +00:00
|
|
|
/* Pointer to the original BIOS entry: */
|
|
|
|
struct e820_entry *pbios;
|
|
|
|
/* Address for this change point: */
|
|
|
|
unsigned long long addr;
|
2011-11-15 22:46:50 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static int __init cpcompare(const void *a, const void *b)
|
|
|
|
{
|
|
|
|
struct change_member * const *app = a, * const *bpp = b;
|
|
|
|
const struct change_member *ap = *app, *bp = *bpp;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Inputs are pointers to two elements of change_point[]. If their
|
2017-01-28 10:13:08 +00:00
|
|
|
* addresses are not equal, their difference dominates. If the addresses
|
2011-11-15 22:46:50 +00:00
|
|
|
* are equal, then consider one that represents the end of its region
|
|
|
|
* to be greater than one that does not.
|
|
|
|
*/
|
|
|
|
if (ap->addr != bp->addr)
|
|
|
|
return ap->addr > bp->addr ? 1 : -1;
|
|
|
|
|
|
|
|
return (ap->addr != ap->pbios->addr) - (bp->addr != bp->pbios->addr);
|
|
|
|
}
|
2008-05-14 15:15:52 +00:00
|
|
|
|
2017-01-28 13:09:20 +00:00
|
|
|
int __init e820__update_table(struct e820_entry *biosmap, int max_nr_map, u32 *pnr_map)
|
2008-05-11 07:30:15 +00:00
|
|
|
{
|
2008-06-22 14:21:57 +00:00
|
|
|
static struct change_member change_point_list[2*E820_X_MAX] __initdata;
|
|
|
|
static struct change_member *change_point[2*E820_X_MAX] __initdata;
|
2017-01-27 11:54:38 +00:00
|
|
|
static struct e820_entry *overlap_list[E820_X_MAX] __initdata;
|
|
|
|
static struct e820_entry new_bios[E820_X_MAX] __initdata;
|
2008-05-11 07:30:15 +00:00
|
|
|
unsigned long current_type, last_type;
|
|
|
|
unsigned long long last_addr;
|
2011-11-15 22:46:50 +00:00
|
|
|
int chgidx;
|
2008-05-11 07:30:15 +00:00
|
|
|
int overlap_entries;
|
|
|
|
int new_bios_entry;
|
|
|
|
int old_nr, new_nr, chg_nr;
|
|
|
|
int i;
|
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/* If there's only one memory region, don't bother: */
|
2008-05-11 07:30:15 +00:00
|
|
|
if (*pnr_map < 2)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
old_nr = *pnr_map;
|
2008-05-14 15:15:46 +00:00
|
|
|
BUG_ON(old_nr > max_nr_map);
|
2008-05-11 07:30:15 +00:00
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/* Bail out if we find any unreasonable addresses in the BIOS map: */
|
|
|
|
for (i = 0; i < old_nr; i++) {
|
2008-05-11 07:30:15 +00:00
|
|
|
if (biosmap[i].addr + biosmap[i].size < biosmap[i].addr)
|
|
|
|
return -1;
|
2017-01-28 10:13:08 +00:00
|
|
|
}
|
2008-05-11 07:30:15 +00:00
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/* Create pointers for initial change-point information (for sorting): */
|
2008-05-11 07:30:15 +00:00
|
|
|
for (i = 0; i < 2 * old_nr; i++)
|
|
|
|
change_point[i] = &change_point_list[i];
|
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/*
|
|
|
|
* Record all known change-points (starting and ending addresses),
|
|
|
|
* omitting empty memory regions:
|
|
|
|
*/
|
2008-05-11 07:30:15 +00:00
|
|
|
chgidx = 0;
|
|
|
|
for (i = 0; i < old_nr; i++) {
|
|
|
|
if (biosmap[i].size != 0) {
|
2017-01-28 10:13:08 +00:00
|
|
|
change_point[chgidx]->addr = biosmap[i].addr;
|
|
|
|
change_point[chgidx++]->pbios = &biosmap[i];
|
|
|
|
change_point[chgidx]->addr = biosmap[i].addr + biosmap[i].size;
|
|
|
|
change_point[chgidx++]->pbios = &biosmap[i];
|
2008-05-11 07:30:15 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
chg_nr = chgidx;
|
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/* Sort change-point list by memory addresses (low -> high): */
|
2011-11-15 22:48:56 +00:00
|
|
|
sort(change_point, chg_nr, sizeof *change_point, cpcompare, NULL);
|
2008-05-11 07:30:15 +00:00
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/* Create a new BIOS memory map, removing overlaps: */
|
|
|
|
overlap_entries = 0; /* Number of entries in the overlap table */
|
|
|
|
new_bios_entry = 0; /* Index for creating new bios map entries */
|
|
|
|
last_type = 0; /* Start with undefined memory type */
|
|
|
|
last_addr = 0; /* Start with 0 as last starting address */
|
2008-05-11 07:30:15 +00:00
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/* Loop through change-points, determining effect on the new BIOS map: */
|
2008-05-11 07:30:15 +00:00
|
|
|
for (chgidx = 0; chgidx < chg_nr; chgidx++) {
|
2017-01-28 10:13:08 +00:00
|
|
|
/* Keep track of all overlapping BIOS entries */
|
|
|
|
if (change_point[chgidx]->addr == change_point[chgidx]->pbios->addr) {
|
|
|
|
/* Add map entry to overlap list (> 1 entry implies an overlap) */
|
|
|
|
overlap_list[overlap_entries++] = change_point[chgidx]->pbios;
|
2008-05-11 07:30:15 +00:00
|
|
|
} else {
|
2017-01-28 10:13:08 +00:00
|
|
|
/* Remove entry from list (order independent, so swap with last): */
|
2008-05-11 07:30:15 +00:00
|
|
|
for (i = 0; i < overlap_entries; i++) {
|
2017-01-28 10:13:08 +00:00
|
|
|
if (overlap_list[i] == change_point[chgidx]->pbios)
|
|
|
|
overlap_list[i] = overlap_list[overlap_entries-1];
|
2008-05-11 07:30:15 +00:00
|
|
|
}
|
|
|
|
overlap_entries--;
|
|
|
|
}
|
|
|
|
/*
|
2017-01-28 10:13:08 +00:00
|
|
|
* If there are overlapping entries, decide which
|
2008-05-11 07:30:15 +00:00
|
|
|
* "type" to use (larger value takes precedence --
|
|
|
|
* 1=usable, 2,3,4,4+=unusable)
|
|
|
|
*/
|
|
|
|
current_type = 0;
|
2017-01-28 10:13:08 +00:00
|
|
|
for (i = 0; i < overlap_entries; i++) {
|
2008-05-11 07:30:15 +00:00
|
|
|
if (overlap_list[i]->type > current_type)
|
|
|
|
current_type = overlap_list[i]->type;
|
2017-01-28 10:13:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Continue building up new BIOS map based on this information: */
|
2016-10-12 18:01:48 +00:00
|
|
|
if (current_type != last_type || current_type == E820_PRAM) {
|
2008-05-11 07:30:15 +00:00
|
|
|
if (last_type != 0) {
|
2017-01-28 10:13:08 +00:00
|
|
|
new_bios[new_bios_entry].size = change_point[chgidx]->addr - last_addr;
|
|
|
|
/* Move forward only if the new size was non-zero: */
|
2008-05-11 07:30:15 +00:00
|
|
|
if (new_bios[new_bios_entry].size != 0)
|
2017-01-28 10:13:08 +00:00
|
|
|
/* No more space left for new BIOS entries? */
|
2008-05-14 15:15:34 +00:00
|
|
|
if (++new_bios_entry >= max_nr_map)
|
2008-05-11 07:30:15 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (current_type != 0) {
|
2017-01-28 10:13:08 +00:00
|
|
|
new_bios[new_bios_entry].addr = change_point[chgidx]->addr;
|
2008-05-11 07:30:15 +00:00
|
|
|
new_bios[new_bios_entry].type = current_type;
|
|
|
|
last_addr = change_point[chgidx]->addr;
|
|
|
|
}
|
|
|
|
last_type = current_type;
|
|
|
|
}
|
|
|
|
}
|
2017-01-28 10:13:08 +00:00
|
|
|
|
|
|
|
/* Retain count for new BIOS entries: */
|
2008-05-11 07:30:15 +00:00
|
|
|
new_nr = new_bios_entry;
|
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/* Copy new BIOS mapping into the original location: */
|
|
|
|
memcpy(biosmap, new_bios, new_nr*sizeof(struct e820_entry));
|
2008-05-11 07:30:15 +00:00
|
|
|
*pnr_map = new_nr;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-01-27 12:54:38 +00:00
|
|
|
static int __init __append_e820_table(struct e820_entry *biosmap, int nr_map)
|
2008-06-11 03:33:39 +00:00
|
|
|
{
|
|
|
|
while (nr_map) {
|
|
|
|
u64 start = biosmap->addr;
|
|
|
|
u64 size = biosmap->size;
|
2016-08-20 01:40:13 +00:00
|
|
|
u64 end = start + size - 1;
|
2008-06-11 03:33:39 +00:00
|
|
|
u32 type = biosmap->type;
|
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/* Ignore the entry on 64-bit overflow: */
|
2016-08-20 01:40:13 +00:00
|
|
|
if (start > end && likely(size))
|
2008-06-11 03:33:39 +00:00
|
|
|
return -1;
|
|
|
|
|
x86/boot/e820: Create coherent API function names for E820 range operations
We have these three related functions:
extern void e820_add_region(u64 start, u64 size, int type);
extern u64 e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);
But it's not clear from the naming that they are 3 operations based around the
same 'memory range' concept. Rename them to better signal this, and move
the prototypes next to each other:
extern void e820__range_add (u64 start, u64 size, int type);
extern u64 e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);
Note that this improved organization of the functions shows another problem that was easy
to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
will be fixed in a separate patch.
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 13:19:36 +00:00
|
|
|
e820__range_add(start, size, type);
|
2008-06-11 03:33:39 +00:00
|
|
|
|
|
|
|
biosmap++;
|
|
|
|
nr_map--;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-05-11 07:30:15 +00:00
|
|
|
/*
|
2017-01-28 10:13:08 +00:00
|
|
|
* Copy the BIOS E820 map into a safe place.
|
2008-05-11 07:30:15 +00:00
|
|
|
*
|
|
|
|
* Sanity-check it while we're at it..
|
|
|
|
*
|
|
|
|
* If we're lucky and live on a modern system, the setup code
|
|
|
|
* will have given us a memory map that we can use to properly
|
|
|
|
* set up memory. If we aren't, we'll fake a memory map.
|
|
|
|
*/
|
2017-01-27 12:54:38 +00:00
|
|
|
static int __init append_e820_table(struct e820_entry *biosmap, int nr_map)
|
2008-05-11 07:30:15 +00:00
|
|
|
{
|
|
|
|
/* Only one memory region (or negative)? Ignore it */
|
|
|
|
if (nr_map < 2)
|
|
|
|
return -1;
|
|
|
|
|
2017-01-27 12:54:38 +00:00
|
|
|
return __append_e820_table(biosmap, nr_map);
|
2008-05-11 07:30:15 +00:00
|
|
|
}
|
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
static u64 __init
|
x86/boot/e820: Create coherent API function names for E820 range operations
We have these three related functions:
extern void e820_add_region(u64 start, u64 size, int type);
extern u64 e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);
But it's not clear from the naming that they are 3 operations based around the
same 'memory range' concept. Rename them to better signal this, and move
the prototypes next to each other:
extern void e820__range_add (u64 start, u64 size, int type);
extern u64 e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);
Note that this improved organization of the functions shows another problem that was easy
to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
will be fixed in a separate patch.
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 13:19:36 +00:00
|
|
|
__e820__range_update(struct e820_table *table, u64 start, u64 size, unsigned old_type, unsigned new_type)
|
2008-05-11 07:30:15 +00:00
|
|
|
{
|
2009-03-13 05:36:01 +00:00
|
|
|
u64 end;
|
2009-03-13 04:35:18 +00:00
|
|
|
unsigned int i;
|
2008-05-11 07:30:15 +00:00
|
|
|
u64 real_updated_size = 0;
|
|
|
|
|
|
|
|
BUG_ON(old_type == new_type);
|
|
|
|
|
2008-06-24 21:58:38 +00:00
|
|
|
if (size > (ULLONG_MAX - start))
|
|
|
|
size = ULLONG_MAX - start;
|
|
|
|
|
2009-03-13 05:36:01 +00:00
|
|
|
end = start + size;
|
2017-01-28 11:27:45 +00:00
|
|
|
pr_debug("e820: update [mem %#010Lx-%#010Lx] ", start, end - 1);
|
2009-03-15 07:59:19 +00:00
|
|
|
e820_print_type(old_type);
|
2017-01-28 11:27:45 +00:00
|
|
|
pr_cont(" ==> ");
|
2009-03-15 07:59:19 +00:00
|
|
|
e820_print_type(new_type);
|
2017-01-28 11:27:45 +00:00
|
|
|
pr_cont("\n");
|
2009-03-15 07:59:19 +00:00
|
|
|
|
2017-01-27 13:06:21 +00:00
|
|
|
for (i = 0; i < table->nr_entries; i++) {
|
2017-01-28 11:16:17 +00:00
|
|
|
struct e820_entry *entry = &table->entries[i];
|
2008-05-11 07:30:15 +00:00
|
|
|
u64 final_start, final_end;
|
2017-01-28 11:16:17 +00:00
|
|
|
u64 entry_end;
|
2009-03-13 05:36:01 +00:00
|
|
|
|
2017-01-28 11:16:17 +00:00
|
|
|
if (entry->type != old_type)
|
2008-05-11 07:30:15 +00:00
|
|
|
continue;
|
2009-03-13 05:36:01 +00:00
|
|
|
|
2017-01-28 11:16:17 +00:00
|
|
|
entry_end = entry->addr + entry->size;
|
2017-01-28 10:13:08 +00:00
|
|
|
|
|
|
|
/* Completely covered by new range? */
|
2017-01-28 11:16:17 +00:00
|
|
|
if (entry->addr >= start && entry_end <= end) {
|
|
|
|
entry->type = new_type;
|
|
|
|
real_updated_size += entry->size;
|
2008-05-11 07:30:15 +00:00
|
|
|
continue;
|
|
|
|
}
|
2009-03-13 05:36:01 +00:00
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/* New range is completely covered? */
|
2017-01-28 11:16:17 +00:00
|
|
|
if (entry->addr < start && entry_end > end) {
|
x86/boot/e820: Create coherent API function names for E820 range operations
We have these three related functions:
extern void e820_add_region(u64 start, u64 size, int type);
extern u64 e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);
But it's not clear from the naming that they are 3 operations based around the
same 'memory range' concept. Rename them to better signal this, and move
the prototypes next to each other:
extern void e820__range_add (u64 start, u64 size, int type);
extern u64 e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);
Note that this improved organization of the functions shows another problem that was easy
to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
will be fixed in a separate patch.
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 13:19:36 +00:00
|
|
|
__e820__range_add(table, start, size, new_type);
|
|
|
|
__e820__range_add(table, end, entry_end - end, entry->type);
|
2017-01-28 11:16:17 +00:00
|
|
|
entry->size = start - entry->addr;
|
2009-03-13 05:36:01 +00:00
|
|
|
real_updated_size += size;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/* Partially covered: */
|
2017-01-28 11:16:17 +00:00
|
|
|
final_start = max(start, entry->addr);
|
|
|
|
final_end = min(end, entry_end);
|
2008-05-11 07:30:15 +00:00
|
|
|
if (final_start >= final_end)
|
|
|
|
continue;
|
2009-03-12 13:07:23 +00:00
|
|
|
|
x86/boot/e820: Create coherent API function names for E820 range operations
We have these three related functions:
extern void e820_add_region(u64 start, u64 size, int type);
extern u64 e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);
But it's not clear from the naming that they are 3 operations based around the
same 'memory range' concept. Rename them to better signal this, and move
the prototypes next to each other:
extern void e820__range_add (u64 start, u64 size, int type);
extern u64 e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);
Note that this improved organization of the functions shows another problem that was easy
to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
will be fixed in a separate patch.
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 13:19:36 +00:00
|
|
|
__e820__range_add(table, final_start, final_end - final_start, new_type);
|
2009-03-12 13:07:23 +00:00
|
|
|
|
2008-05-11 07:30:15 +00:00
|
|
|
real_updated_size += final_end - final_start;
|
2008-06-24 21:55:32 +00:00
|
|
|
|
2009-03-13 04:35:18 +00:00
|
|
|
/*
|
2017-01-28 10:13:08 +00:00
|
|
|
* Left range could be head or tail, so need to update
|
|
|
|
* its size first:
|
2009-03-13 04:35:18 +00:00
|
|
|
*/
|
2017-01-28 11:16:17 +00:00
|
|
|
entry->size -= final_end - final_start;
|
|
|
|
if (entry->addr < final_start)
|
2008-06-24 21:55:32 +00:00
|
|
|
continue;
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2017-01-28 11:16:17 +00:00
|
|
|
entry->addr = final_end;
|
2008-05-11 07:30:15 +00:00
|
|
|
}
|
|
|
|
return real_updated_size;
|
|
|
|
}
|
|
|
|
|
x86/boot/e820: Create coherent API function names for E820 range operations
We have these three related functions:
extern void e820_add_region(u64 start, u64 size, int type);
extern u64 e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);
But it's not clear from the naming that they are 3 operations based around the
same 'memory range' concept. Rename them to better signal this, and move
the prototypes next to each other:
extern void e820__range_add (u64 start, u64 size, int type);
extern u64 e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);
Note that this improved organization of the functions shows another problem that was easy
to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
will be fixed in a separate patch.
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 13:19:36 +00:00
|
|
|
u64 __init e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type)
|
2008-07-03 18:39:00 +00:00
|
|
|
{
|
x86/boot/e820: Create coherent API function names for E820 range operations
We have these three related functions:
extern void e820_add_region(u64 start, u64 size, int type);
extern u64 e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);
But it's not clear from the naming that they are 3 operations based around the
same 'memory range' concept. Rename them to better signal this, and move
the prototypes next to each other:
extern void e820__range_add (u64 start, u64 size, int type);
extern u64 e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);
Note that this improved organization of the functions shows another problem that was easy
to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
will be fixed in a separate patch.
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 13:19:36 +00:00
|
|
|
return __e820__range_update(e820_table, start, size, old_type, new_type);
|
2008-07-03 18:39:00 +00:00
|
|
|
}
|
|
|
|
|
x86/boot/e820: Create coherent API function names for E820 range operations
We have these three related functions:
extern void e820_add_region(u64 start, u64 size, int type);
extern u64 e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);
But it's not clear from the naming that they are 3 operations based around the
same 'memory range' concept. Rename them to better signal this, and move
the prototypes next to each other:
extern void e820__range_add (u64 start, u64 size, int type);
extern u64 e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);
Note that this improved organization of the functions shows another problem that was easy
to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
will be fixed in a separate patch.
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 13:19:36 +00:00
|
|
|
static u64 __init e820__range_update_firmware(u64 start, u64 size, unsigned old_type, unsigned new_type)
|
2008-07-03 18:39:00 +00:00
|
|
|
{
|
x86/boot/e820: Create coherent API function names for E820 range operations
We have these three related functions:
extern void e820_add_region(u64 start, u64 size, int type);
extern u64 e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);
But it's not clear from the naming that they are 3 operations based around the
same 'memory range' concept. Rename them to better signal this, and move
the prototypes next to each other:
extern void e820__range_add (u64 start, u64 size, int type);
extern u64 e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);
Note that this improved organization of the functions shows another problem that was easy
to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
will be fixed in a separate patch.
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 13:19:36 +00:00
|
|
|
return __e820__range_update(e820_table_firmware, start, size, old_type, new_type);
|
2008-07-03 18:39:00 +00:00
|
|
|
}
|
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/* Remove a range of memory from the E820 table: */
|
x86/boot/e820: Create coherent API function names for E820 range operations
We have these three related functions:
extern void e820_add_region(u64 start, u64 size, int type);
extern u64 e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);
But it's not clear from the naming that they are 3 operations based around the
same 'memory range' concept. Rename them to better signal this, and move
the prototypes next to each other:
extern void e820__range_add (u64 start, u64 size, int type);
extern u64 e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);
Note that this improved organization of the functions shows another problem that was easy
to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
will be fixed in a separate patch.
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 13:19:36 +00:00
|
|
|
u64 __init e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype)
|
2008-06-21 21:48:05 +00:00
|
|
|
{
|
|
|
|
int i;
|
2010-01-22 03:21:04 +00:00
|
|
|
u64 end;
|
2008-06-21 21:48:05 +00:00
|
|
|
u64 real_removed_size = 0;
|
|
|
|
|
2008-06-24 21:58:38 +00:00
|
|
|
if (size > (ULLONG_MAX - start))
|
|
|
|
size = ULLONG_MAX - start;
|
|
|
|
|
2010-01-22 03:21:04 +00:00
|
|
|
end = start + size;
|
2017-01-28 11:27:45 +00:00
|
|
|
pr_debug("e820: remove [mem %#010Lx-%#010Lx] ", start, end - 1);
|
2010-03-30 05:38:29 +00:00
|
|
|
if (checktype)
|
|
|
|
e820_print_type(old_type);
|
2017-01-28 11:27:45 +00:00
|
|
|
pr_cont("\n");
|
2010-01-22 03:21:04 +00:00
|
|
|
|
2017-01-27 13:06:21 +00:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
2017-01-28 11:16:17 +00:00
|
|
|
struct e820_entry *entry = &e820_table->entries[i];
|
2008-06-21 21:48:05 +00:00
|
|
|
u64 final_start, final_end;
|
2017-01-28 11:16:17 +00:00
|
|
|
u64 entry_end;
|
2008-06-21 21:48:05 +00:00
|
|
|
|
2017-01-28 11:16:17 +00:00
|
|
|
if (checktype && entry->type != old_type)
|
2008-06-21 21:48:05 +00:00
|
|
|
continue;
|
2010-03-30 05:38:29 +00:00
|
|
|
|
2017-01-28 11:16:17 +00:00
|
|
|
entry_end = entry->addr + entry->size;
|
2017-01-28 10:13:08 +00:00
|
|
|
|
|
|
|
/* Completely covered? */
|
2017-01-28 11:16:17 +00:00
|
|
|
if (entry->addr >= start && entry_end <= end) {
|
|
|
|
real_removed_size += entry->size;
|
|
|
|
memset(entry, 0, sizeof(struct e820_entry));
|
2008-06-21 21:48:05 +00:00
|
|
|
continue;
|
|
|
|
}
|
2010-03-30 05:38:29 +00:00
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/* Is the new range completely covered? */
|
2017-01-28 11:16:17 +00:00
|
|
|
if (entry->addr < start && entry_end > end) {
|
x86/boot/e820: Create coherent API function names for E820 range operations
We have these three related functions:
extern void e820_add_region(u64 start, u64 size, int type);
extern u64 e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);
But it's not clear from the naming that they are 3 operations based around the
same 'memory range' concept. Rename them to better signal this, and move
the prototypes next to each other:
extern void e820__range_add (u64 start, u64 size, int type);
extern u64 e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);
Note that this improved organization of the functions shows another problem that was easy
to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
will be fixed in a separate patch.
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 13:19:36 +00:00
|
|
|
e820__range_add(end, entry_end - end, entry->type);
|
2017-01-28 11:16:17 +00:00
|
|
|
entry->size = start - entry->addr;
|
2010-03-30 05:38:29 +00:00
|
|
|
real_removed_size += size;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/* Partially covered: */
|
2017-01-28 11:16:17 +00:00
|
|
|
final_start = max(start, entry->addr);
|
|
|
|
final_end = min(end, entry_end);
|
2008-06-21 21:48:05 +00:00
|
|
|
if (final_start >= final_end)
|
|
|
|
continue;
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2008-06-21 21:48:05 +00:00
|
|
|
real_removed_size += final_end - final_start;
|
|
|
|
|
2010-03-30 05:38:29 +00:00
|
|
|
/*
|
2017-01-28 10:13:08 +00:00
|
|
|
* Left range could be head or tail, so need to update
|
|
|
|
* the size first:
|
2010-03-30 05:38:29 +00:00
|
|
|
*/
|
2017-01-28 11:16:17 +00:00
|
|
|
entry->size -= final_end - final_start;
|
|
|
|
if (entry->addr < final_start)
|
2008-06-21 21:48:05 +00:00
|
|
|
continue;
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2017-01-28 11:16:17 +00:00
|
|
|
entry->addr = final_end;
|
2008-06-21 21:48:05 +00:00
|
|
|
}
|
|
|
|
return real_removed_size;
|
|
|
|
}
|
|
|
|
|
2017-01-28 13:03:04 +00:00
|
|
|
void __init e820__update_table_print(void)
|
2008-05-11 07:30:15 +00:00
|
|
|
{
|
2017-01-28 13:09:20 +00:00
|
|
|
if (e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries))
|
2008-05-11 07:30:15 +00:00
|
|
|
return;
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2017-01-28 11:27:45 +00:00
|
|
|
pr_info("e820: modified physical RAM map:\n");
|
2017-01-28 13:24:02 +00:00
|
|
|
e820__print_table("modified");
|
2008-05-11 07:30:15 +00:00
|
|
|
}
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2017-01-28 13:03:04 +00:00
|
|
|
static void __init e820__update_table_firmware(void)
|
2008-07-03 18:39:00 +00:00
|
|
|
{
|
2017-01-28 13:09:20 +00:00
|
|
|
e820__update_table(e820_table_firmware->entries, ARRAY_SIZE(e820_table_firmware->entries), &e820_table_firmware->nr_entries);
|
2008-07-03 18:39:00 +00:00
|
|
|
}
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2008-06-25 18:02:42 +00:00
|
|
|
#define MAX_GAP_END 0x100000000ull
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2008-05-11 07:30:15 +00:00
|
|
|
/*
|
2017-01-28 10:13:08 +00:00
|
|
|
* Search for a gap in the E820 memory space from 0 to MAX_GAP_END (4GB).
|
2008-05-11 07:30:15 +00:00
|
|
|
*/
|
2017-01-28 10:13:08 +00:00
|
|
|
static int __init e820_search_gap(unsigned long *gapstart, unsigned long *gapsize)
|
2008-05-11 07:30:15 +00:00
|
|
|
{
|
2016-12-25 14:35:51 +00:00
|
|
|
unsigned long long last = MAX_GAP_END;
|
2017-01-27 13:06:21 +00:00
|
|
|
int i = e820_table->nr_entries;
|
2008-05-11 07:30:15 +00:00
|
|
|
int found = 0;
|
|
|
|
|
|
|
|
while (--i >= 0) {
|
2017-01-27 13:06:21 +00:00
|
|
|
unsigned long long start = e820_table->entries[i].addr;
|
|
|
|
unsigned long long end = start + e820_table->entries[i].size;
|
2008-05-11 07:30:15 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Since "last" is at most 4GB, we know we'll
|
2017-01-28 10:13:08 +00:00
|
|
|
* fit in 32 bits if this condition is true:
|
2008-05-11 07:30:15 +00:00
|
|
|
*/
|
|
|
|
if (last > end) {
|
|
|
|
unsigned long gap = last - end;
|
|
|
|
|
2008-06-24 18:48:30 +00:00
|
|
|
if (gap >= *gapsize) {
|
|
|
|
*gapsize = gap;
|
|
|
|
*gapstart = end;
|
2008-05-11 07:30:15 +00:00
|
|
|
found = 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (start < last)
|
|
|
|
last = start;
|
|
|
|
}
|
2008-06-24 18:48:30 +00:00
|
|
|
return found;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2017-01-28 10:13:08 +00:00
|
|
|
* Search for the biggest gap in the low 32 bits of the E820
|
|
|
|
* memory space. We pass this space to the PCI subsystem, so
|
|
|
|
* that it can assign MMIO resources for hotplug or
|
|
|
|
* unconfigured devices in.
|
|
|
|
*
|
2008-06-24 18:48:30 +00:00
|
|
|
* Hopefully the BIOS let enough space left.
|
|
|
|
*/
|
2017-01-28 13:16:38 +00:00
|
|
|
__init void e820__setup_pci_gap(void)
|
2008-06-24 18:48:30 +00:00
|
|
|
{
|
2009-05-06 15:07:52 +00:00
|
|
|
unsigned long gapstart, gapsize;
|
2008-06-24 18:48:30 +00:00
|
|
|
int found;
|
|
|
|
|
|
|
|
gapsize = 0x400000;
|
2016-12-25 14:35:51 +00:00
|
|
|
found = e820_search_gap(&gapstart, &gapsize);
|
2008-05-11 07:30:15 +00:00
|
|
|
|
|
|
|
if (!found) {
|
2017-01-11 14:49:04 +00:00
|
|
|
#ifdef CONFIG_X86_64
|
2008-06-25 05:14:09 +00:00
|
|
|
gapstart = (max_pfn << PAGE_SHIFT) + 1024*1024;
|
2017-01-28 11:27:45 +00:00
|
|
|
pr_err(
|
2017-01-28 10:13:08 +00:00
|
|
|
"e820: Cannot find an available gap in the 32-bit address range\n"
|
|
|
|
"e820: PCI devices with unassigned 32-bit BARs may not work!\n");
|
2017-01-11 14:49:04 +00:00
|
|
|
#else
|
|
|
|
gapstart = 0x10000000;
|
2008-05-11 07:30:15 +00:00
|
|
|
#endif
|
2017-01-11 14:49:04 +00:00
|
|
|
}
|
2008-05-11 07:30:15 +00:00
|
|
|
|
|
|
|
/*
|
2009-05-06 15:07:52 +00:00
|
|
|
* e820_reserve_resources_late protect stolen RAM already
|
2008-05-11 07:30:15 +00:00
|
|
|
*/
|
2009-05-06 15:07:52 +00:00
|
|
|
pci_mem_start = gapstart;
|
2008-05-11 07:30:15 +00:00
|
|
|
|
2017-01-28 11:27:45 +00:00
|
|
|
pr_info("e820: [mem %#010lx-%#010lx] available for PCI devices\n", gapstart, gapstart + gapsize - 1);
|
2008-05-11 07:30:15 +00:00
|
|
|
}
|
|
|
|
|
2016-09-17 21:39:26 +00:00
|
|
|
/*
|
|
|
|
* Called late during init, in free_initmem().
|
|
|
|
*
|
2017-01-28 10:13:08 +00:00
|
|
|
* Initial e820_table and e820_table_firmware are largish __initdata arrays.
|
|
|
|
*
|
|
|
|
* Copy them to a (usually much smaller) dynamically allocated area that is
|
|
|
|
* sized precisely after the number of e820 entries.
|
|
|
|
*
|
|
|
|
* This is done after we've performed all the fixes and tweaks to the tables.
|
|
|
|
* All functions which modify them are __init functions, which won't exist
|
|
|
|
* after free_initmem().
|
2016-09-17 21:39:26 +00:00
|
|
|
*/
|
|
|
|
__init void e820_reallocate_tables(void)
|
|
|
|
{
|
2017-01-27 12:54:38 +00:00
|
|
|
struct e820_table *n;
|
2016-09-17 21:39:26 +00:00
|
|
|
int size;
|
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
size = offsetof(struct e820_table, entries) + sizeof(struct e820_entry)*e820_table->nr_entries;
|
2016-09-17 21:39:26 +00:00
|
|
|
n = kmalloc(size, GFP_KERNEL);
|
|
|
|
BUG_ON(!n);
|
2017-01-27 12:54:38 +00:00
|
|
|
memcpy(n, e820_table, size);
|
|
|
|
e820_table = n;
|
2016-09-17 21:39:26 +00:00
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
size = offsetof(struct e820_table, entries) + sizeof(struct e820_entry)*e820_table_firmware->nr_entries;
|
2016-09-17 21:39:26 +00:00
|
|
|
n = kmalloc(size, GFP_KERNEL);
|
|
|
|
BUG_ON(!n);
|
2017-01-28 09:07:49 +00:00
|
|
|
memcpy(n, e820_table_firmware, size);
|
|
|
|
e820_table_firmware = n;
|
2016-09-17 21:39:26 +00:00
|
|
|
}
|
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/*
|
|
|
|
* Because of the small fixed size of struct boot_params, only the first
|
|
|
|
* 128 E820 memory entries are passed to the kernel via boot_params.e820_table,
|
|
|
|
* the remaining (if any) entries are passed via the SETUP_E820_EXT node of
|
|
|
|
* struct setup_data, which is parsed here.
|
2008-06-11 03:33:39 +00:00
|
|
|
*/
|
2017-01-28 12:18:40 +00:00
|
|
|
void __init e820__memory_setup_extended(u64 phys_addr, u32 data_len)
|
2008-06-11 03:33:39 +00:00
|
|
|
{
|
|
|
|
int entries;
|
2017-01-27 11:54:38 +00:00
|
|
|
struct e820_entry *extmap;
|
2013-08-13 21:46:41 +00:00
|
|
|
struct setup_data *sdata;
|
2008-06-11 03:33:39 +00:00
|
|
|
|
2013-08-13 21:46:41 +00:00
|
|
|
sdata = early_memremap(phys_addr, data_len);
|
2017-01-27 11:54:38 +00:00
|
|
|
entries = sdata->len / sizeof(struct e820_entry);
|
|
|
|
extmap = (struct e820_entry *)(sdata->data);
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2017-01-27 12:54:38 +00:00
|
|
|
__append_e820_table(extmap, entries);
|
2017-01-28 13:09:20 +00:00
|
|
|
e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2015-02-24 09:13:28 +00:00
|
|
|
early_memunmap(sdata, data_len);
|
2017-01-28 11:27:45 +00:00
|
|
|
pr_info("e820: extended physical RAM map:\n");
|
2017-01-28 13:24:02 +00:00
|
|
|
e820__print_table("extended");
|
2008-06-11 03:33:39 +00:00
|
|
|
}
|
|
|
|
|
2008-05-21 03:10:58 +00:00
|
|
|
/**
|
|
|
|
* Find the ranges of physical addresses that do not correspond to
|
2017-01-28 10:13:08 +00:00
|
|
|
* E820 RAM areas and mark the corresponding pages as 'nosave' for
|
|
|
|
* hibernation (32-bit) or software suspend and suspend to RAM (64-bit).
|
2008-05-21 03:10:58 +00:00
|
|
|
*
|
2017-01-28 10:13:08 +00:00
|
|
|
* This function requires the E820 map to be sorted and without any
|
2014-09-12 03:03:58 +00:00
|
|
|
* overlapping entries.
|
2008-05-21 03:10:58 +00:00
|
|
|
*/
|
|
|
|
void __init e820_mark_nosave_regions(unsigned long limit_pfn)
|
|
|
|
{
|
|
|
|
int i;
|
2014-09-12 03:03:58 +00:00
|
|
|
unsigned long pfn = 0;
|
2008-05-21 03:10:58 +00:00
|
|
|
|
2017-01-27 13:06:21 +00:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
2017-01-28 11:16:17 +00:00
|
|
|
struct e820_entry *entry = &e820_table->entries[i];
|
2008-05-21 03:10:58 +00:00
|
|
|
|
2017-01-28 11:16:17 +00:00
|
|
|
if (pfn < PFN_UP(entry->addr))
|
|
|
|
register_nosave_region(pfn, PFN_UP(entry->addr));
|
2008-05-21 03:10:58 +00:00
|
|
|
|
2017-01-28 11:16:17 +00:00
|
|
|
pfn = PFN_DOWN(entry->addr + entry->size);
|
2015-04-01 07:12:18 +00:00
|
|
|
|
2017-01-28 11:16:17 +00:00
|
|
|
if (entry->type != E820_RAM && entry->type != E820_RESERVED_KERN)
|
|
|
|
register_nosave_region(PFN_UP(entry->addr), pfn);
|
2008-05-21 03:10:58 +00:00
|
|
|
|
|
|
|
if (pfn >= limit_pfn)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2008-05-18 08:18:57 +00:00
|
|
|
|
2011-12-08 03:25:49 +00:00
|
|
|
#ifdef CONFIG_ACPI
|
2017-01-28 10:13:08 +00:00
|
|
|
/*
|
|
|
|
* Register ACPI NVS memory regions, so that we can save/restore them during
|
|
|
|
* hibernation and the subsequent resume:
|
2008-10-31 00:02:41 +00:00
|
|
|
*/
|
|
|
|
static int __init e820_mark_nvs_memory(void)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2017-01-27 13:06:21 +00:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
2017-01-28 11:16:17 +00:00
|
|
|
struct e820_entry *entry = &e820_table->entries[i];
|
2008-10-31 00:02:41 +00:00
|
|
|
|
2017-01-28 11:16:17 +00:00
|
|
|
if (entry->type == E820_NVS)
|
|
|
|
acpi_nvs_register(entry->addr, entry->size);
|
2008-10-31 00:02:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
core_initcall(e820_mark_nvs_memory);
|
|
|
|
#endif
|
|
|
|
|
2008-06-01 20:17:38 +00:00
|
|
|
/*
|
2017-01-28 12:46:28 +00:00
|
|
|
* Allocate the requested number of bytes with the requsted alignment
|
|
|
|
* and return (the physical address) to the caller. Also register this
|
|
|
|
* range in the 'firmware' E820 table as a reserved range.
|
|
|
|
*
|
|
|
|
* This allows kexec to fake a new mptable, as if it came from the real
|
|
|
|
* system.
|
2008-06-01 20:17:38 +00:00
|
|
|
*/
|
2017-01-28 12:46:28 +00:00
|
|
|
u64 __init e820__memblock_alloc_reserved(u64 size, u64 align)
|
2008-06-01 20:17:38 +00:00
|
|
|
{
|
|
|
|
u64 addr;
|
|
|
|
|
2011-07-12 09:15:58 +00:00
|
|
|
addr = __memblock_alloc_base(size, align, MEMBLOCK_ALLOC_ACCESSIBLE);
|
|
|
|
if (addr) {
|
x86/boot/e820: Create coherent API function names for E820 range operations
We have these three related functions:
extern void e820_add_region(u64 start, u64 size, int type);
extern u64 e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);
But it's not clear from the naming that they are 3 operations based around the
same 'memory range' concept. Rename them to better signal this, and move
the prototypes next to each other:
extern void e820__range_add (u64 start, u64 size, int type);
extern u64 e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);
Note that this improved organization of the functions shows another problem that was easy
to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
will be fixed in a separate patch.
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 13:19:36 +00:00
|
|
|
e820__range_update_firmware(addr, size, E820_RAM, E820_RESERVED);
|
2017-01-28 12:46:28 +00:00
|
|
|
pr_info("e820: update e820_table_firmware for e820__memblock_alloc_reserved()\n");
|
2017-01-28 13:03:04 +00:00
|
|
|
e820__update_table_firmware();
|
2009-05-06 12:02:19 +00:00
|
|
|
}
|
2008-06-01 20:17:38 +00:00
|
|
|
|
|
|
|
return addr;
|
|
|
|
}
|
|
|
|
|
2008-06-04 02:34:00 +00:00
|
|
|
#ifdef CONFIG_X86_32
|
|
|
|
# ifdef CONFIG_X86_PAE
|
|
|
|
# define MAX_ARCH_PFN (1ULL<<(36-PAGE_SHIFT))
|
|
|
|
# else
|
|
|
|
# define MAX_ARCH_PFN (1ULL<<(32-PAGE_SHIFT))
|
|
|
|
# endif
|
|
|
|
#else /* CONFIG_X86_32 */
|
2008-06-04 20:21:29 +00:00
|
|
|
# define MAX_ARCH_PFN MAXMEM>>PAGE_SHIFT
|
2008-06-04 02:34:00 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Find the highest page frame number we have available
|
|
|
|
*/
|
2016-09-21 19:50:45 +00:00
|
|
|
static unsigned long __init e820_end_pfn(unsigned long limit_pfn, unsigned type)
|
2008-06-04 02:34:00 +00:00
|
|
|
{
|
2008-07-09 01:56:38 +00:00
|
|
|
int i;
|
|
|
|
unsigned long last_pfn = 0;
|
2008-06-04 02:34:00 +00:00
|
|
|
unsigned long max_arch_pfn = MAX_ARCH_PFN;
|
|
|
|
|
2017-01-27 13:06:21 +00:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
2017-01-28 11:16:17 +00:00
|
|
|
struct e820_entry *entry = &e820_table->entries[i];
|
2008-07-11 03:38:26 +00:00
|
|
|
unsigned long start_pfn;
|
2008-07-09 01:56:38 +00:00
|
|
|
unsigned long end_pfn;
|
|
|
|
|
2017-01-28 11:16:17 +00:00
|
|
|
if (entry->type != type)
|
2008-07-09 10:01:14 +00:00
|
|
|
continue;
|
|
|
|
|
2017-01-28 11:16:17 +00:00
|
|
|
start_pfn = entry->addr >> PAGE_SHIFT;
|
|
|
|
end_pfn = (entry->addr + entry->size) >> PAGE_SHIFT;
|
2008-07-11 03:38:26 +00:00
|
|
|
|
|
|
|
if (start_pfn >= limit_pfn)
|
|
|
|
continue;
|
|
|
|
if (end_pfn > limit_pfn) {
|
|
|
|
last_pfn = limit_pfn;
|
|
|
|
break;
|
|
|
|
}
|
2008-07-09 01:56:38 +00:00
|
|
|
if (end_pfn > last_pfn)
|
|
|
|
last_pfn = end_pfn;
|
|
|
|
}
|
2008-06-04 02:34:00 +00:00
|
|
|
|
|
|
|
if (last_pfn > max_arch_pfn)
|
|
|
|
last_pfn = max_arch_pfn;
|
|
|
|
|
2017-01-28 11:27:45 +00:00
|
|
|
pr_info("e820: last_pfn = %#lx max_arch_pfn = %#lx\n",
|
2008-06-04 02:34:00 +00:00
|
|
|
last_pfn, max_arch_pfn);
|
|
|
|
return last_pfn;
|
|
|
|
}
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2008-07-11 03:38:26 +00:00
|
|
|
unsigned long __init e820_end_of_ram_pfn(void)
|
|
|
|
{
|
2016-09-21 19:50:45 +00:00
|
|
|
return e820_end_pfn(MAX_ARCH_PFN, E820_RAM);
|
2008-07-11 03:38:26 +00:00
|
|
|
}
|
2008-06-04 02:34:00 +00:00
|
|
|
|
2008-07-11 03:38:26 +00:00
|
|
|
unsigned long __init e820_end_of_low_ram_pfn(void)
|
|
|
|
{
|
2016-09-21 19:50:45 +00:00
|
|
|
return e820_end_pfn(1UL << (32 - PAGE_SHIFT), E820_RAM);
|
2008-07-11 03:38:26 +00:00
|
|
|
}
|
2008-06-04 02:34:00 +00:00
|
|
|
|
2016-09-17 21:39:25 +00:00
|
|
|
static void __init early_panic(char *msg)
|
2008-06-10 19:55:54 +00:00
|
|
|
{
|
|
|
|
early_printk(msg);
|
|
|
|
panic(msg);
|
|
|
|
}
|
|
|
|
|
2008-07-10 11:17:00 +00:00
|
|
|
static int userdef __initdata;
|
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/* The "mem=nopentium" boot option disables 4MB page tables on 32-bit kernels: */
|
2008-06-10 19:55:54 +00:00
|
|
|
static int __init parse_memopt(char *p)
|
|
|
|
{
|
|
|
|
u64 mem_size;
|
|
|
|
|
|
|
|
if (!p)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (!strcmp(p, "nopentium")) {
|
2011-02-04 01:38:05 +00:00
|
|
|
#ifdef CONFIG_X86_32
|
2008-06-10 19:55:54 +00:00
|
|
|
setup_clear_cpu_cap(X86_FEATURE_PSE);
|
|
|
|
return 0;
|
2011-02-04 01:38:05 +00:00
|
|
|
#else
|
2017-01-28 11:27:45 +00:00
|
|
|
pr_warn("mem=nopentium ignored! (only supported on x86_32)\n");
|
2011-02-04 01:38:05 +00:00
|
|
|
return -EINVAL;
|
2008-06-10 19:55:54 +00:00
|
|
|
#endif
|
2011-02-04 01:38:05 +00:00
|
|
|
}
|
2008-06-10 19:55:54 +00:00
|
|
|
|
2008-07-10 11:17:00 +00:00
|
|
|
userdef = 1;
|
2008-06-10 19:55:54 +00:00
|
|
|
mem_size = memparse(p, &p);
|
2017-01-28 10:13:08 +00:00
|
|
|
|
|
|
|
/* Don't remove all memory when getting "mem={invalid}" parameter: */
|
2011-02-04 01:38:04 +00:00
|
|
|
if (mem_size == 0)
|
|
|
|
return -EINVAL;
|
2017-01-28 10:13:08 +00:00
|
|
|
|
x86/boot/e820: Create coherent API function names for E820 range operations
We have these three related functions:
extern void e820_add_region(u64 start, u64 size, int type);
extern u64 e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);
But it's not clear from the naming that they are 3 operations based around the
same 'memory range' concept. Rename them to better signal this, and move
the prototypes next to each other:
extern void e820__range_add (u64 start, u64 size, int type);
extern u64 e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);
Note that this improved organization of the functions shows another problem that was easy
to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
will be fixed in a separate patch.
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 13:19:36 +00:00
|
|
|
e820__range_remove(mem_size, ULLONG_MAX - mem_size, E820_RAM, 1);
|
2008-06-25 19:39:16 +00:00
|
|
|
|
2008-06-10 19:55:54 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
early_param("mem", parse_memopt);
|
|
|
|
|
2012-11-17 03:39:23 +00:00
|
|
|
static int __init parse_memmap_one(char *p)
|
2008-06-10 19:55:54 +00:00
|
|
|
{
|
|
|
|
char *oldp;
|
|
|
|
u64 start_at, mem_size;
|
|
|
|
|
2008-07-05 11:53:39 +00:00
|
|
|
if (!p)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2008-09-09 13:56:08 +00:00
|
|
|
if (!strncmp(p, "exactmap", 8)) {
|
2008-06-10 19:55:54 +00:00
|
|
|
#ifdef CONFIG_CRASH_DUMP
|
|
|
|
/*
|
|
|
|
* If we are doing a crash dump, we still need to know
|
2017-01-28 10:13:08 +00:00
|
|
|
* the real memory size before the original memory map is
|
2008-06-10 19:55:54 +00:00
|
|
|
* reset.
|
|
|
|
*/
|
2008-07-11 03:38:26 +00:00
|
|
|
saved_max_pfn = e820_end_of_ram_pfn();
|
2008-06-10 19:55:54 +00:00
|
|
|
#endif
|
2017-01-27 13:06:21 +00:00
|
|
|
e820_table->nr_entries = 0;
|
2008-06-10 19:55:54 +00:00
|
|
|
userdef = 1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
oldp = p;
|
|
|
|
mem_size = memparse(p, &p);
|
|
|
|
if (p == oldp)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
userdef = 1;
|
|
|
|
if (*p == '@') {
|
|
|
|
start_at = memparse(p+1, &p);
|
x86/boot/e820: Create coherent API function names for E820 range operations
We have these three related functions:
extern void e820_add_region(u64 start, u64 size, int type);
extern u64 e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);
But it's not clear from the naming that they are 3 operations based around the
same 'memory range' concept. Rename them to better signal this, and move
the prototypes next to each other:
extern void e820__range_add (u64 start, u64 size, int type);
extern u64 e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);
Note that this improved organization of the functions shows another problem that was easy
to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
will be fixed in a separate patch.
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 13:19:36 +00:00
|
|
|
e820__range_add(start_at, mem_size, E820_RAM);
|
2008-06-10 19:55:54 +00:00
|
|
|
} else if (*p == '#') {
|
|
|
|
start_at = memparse(p+1, &p);
|
x86/boot/e820: Create coherent API function names for E820 range operations
We have these three related functions:
extern void e820_add_region(u64 start, u64 size, int type);
extern u64 e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);
But it's not clear from the naming that they are 3 operations based around the
same 'memory range' concept. Rename them to better signal this, and move
the prototypes next to each other:
extern void e820__range_add (u64 start, u64 size, int type);
extern u64 e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);
Note that this improved organization of the functions shows another problem that was easy
to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
will be fixed in a separate patch.
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 13:19:36 +00:00
|
|
|
e820__range_add(start_at, mem_size, E820_ACPI);
|
2008-06-10 19:55:54 +00:00
|
|
|
} else if (*p == '$') {
|
|
|
|
start_at = memparse(p+1, &p);
|
x86/boot/e820: Create coherent API function names for E820 range operations
We have these three related functions:
extern void e820_add_region(u64 start, u64 size, int type);
extern u64 e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);
But it's not clear from the naming that they are 3 operations based around the
same 'memory range' concept. Rename them to better signal this, and move
the prototypes next to each other:
extern void e820__range_add (u64 start, u64 size, int type);
extern u64 e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);
Note that this improved organization of the functions shows another problem that was easy
to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
will be fixed in a separate patch.
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 13:19:36 +00:00
|
|
|
e820__range_add(start_at, mem_size, E820_RESERVED);
|
2015-04-01 07:12:18 +00:00
|
|
|
} else if (*p == '!') {
|
|
|
|
start_at = memparse(p+1, &p);
|
x86/boot/e820: Create coherent API function names for E820 range operations
We have these three related functions:
extern void e820_add_region(u64 start, u64 size, int type);
extern u64 e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);
But it's not clear from the naming that they are 3 operations based around the
same 'memory range' concept. Rename them to better signal this, and move
the prototypes next to each other:
extern void e820__range_add (u64 start, u64 size, int type);
extern u64 e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);
Note that this improved organization of the functions shows another problem that was easy
to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
will be fixed in a separate patch.
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 13:19:36 +00:00
|
|
|
e820__range_add(start_at, mem_size, E820_PRAM);
|
2017-01-28 10:13:08 +00:00
|
|
|
} else {
|
x86/boot/e820: Create coherent API function names for E820 range operations
We have these three related functions:
extern void e820_add_region(u64 start, u64 size, int type);
extern u64 e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);
But it's not clear from the naming that they are 3 operations based around the
same 'memory range' concept. Rename them to better signal this, and move
the prototypes next to each other:
extern void e820__range_add (u64 start, u64 size, int type);
extern u64 e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);
Note that this improved organization of the functions shows another problem that was easy
to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
will be fixed in a separate patch.
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 13:19:36 +00:00
|
|
|
e820__range_remove(mem_size, ULLONG_MAX - mem_size, E820_RAM, 1);
|
2017-01-28 10:13:08 +00:00
|
|
|
}
|
2008-07-13 05:57:07 +00:00
|
|
|
|
2008-06-10 19:55:54 +00:00
|
|
|
return *p == '\0' ? 0 : -EINVAL;
|
|
|
|
}
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2012-11-17 03:39:23 +00:00
|
|
|
static int __init parse_memmap_opt(char *str)
|
|
|
|
{
|
|
|
|
while (str) {
|
|
|
|
char *k = strchr(str, ',');
|
|
|
|
|
|
|
|
if (k)
|
|
|
|
*k++ = 0;
|
|
|
|
|
|
|
|
parse_memmap_one(str);
|
|
|
|
str = k;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2008-06-10 19:55:54 +00:00
|
|
|
early_param("memmap", parse_memmap_opt);
|
|
|
|
|
2017-01-28 12:25:45 +00:00
|
|
|
void __init e820_reserve_setup_data(void)
|
|
|
|
{
|
|
|
|
struct setup_data *data;
|
|
|
|
u64 pa_data;
|
|
|
|
|
|
|
|
pa_data = boot_params.hdr.setup_data;
|
|
|
|
if (!pa_data)
|
|
|
|
return;
|
|
|
|
|
|
|
|
while (pa_data) {
|
|
|
|
data = early_memremap(pa_data, sizeof(*data));
|
x86/boot/e820: Create coherent API function names for E820 range operations
We have these three related functions:
extern void e820_add_region(u64 start, u64 size, int type);
extern u64 e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);
But it's not clear from the naming that they are 3 operations based around the
same 'memory range' concept. Rename them to better signal this, and move
the prototypes next to each other:
extern void e820__range_add (u64 start, u64 size, int type);
extern u64 e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);
Note that this improved organization of the functions shows another problem that was easy
to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
will be fixed in a separate patch.
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 13:19:36 +00:00
|
|
|
e820__range_update(pa_data, sizeof(*data)+data->len, E820_RAM, E820_RESERVED_KERN);
|
2017-01-28 12:25:45 +00:00
|
|
|
pa_data = data->next;
|
|
|
|
early_memunmap(data, sizeof(*data));
|
|
|
|
}
|
|
|
|
|
2017-01-28 13:09:20 +00:00
|
|
|
e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
|
2017-01-28 12:25:45 +00:00
|
|
|
memcpy(e820_table_firmware, e820_table, sizeof(struct e820_table));
|
|
|
|
printk(KERN_INFO "extended physical RAM map:\n");
|
2017-01-28 13:24:02 +00:00
|
|
|
e820__print_table("reserve setup_data");
|
2017-01-28 12:25:45 +00:00
|
|
|
}
|
|
|
|
|
2017-01-28 12:37:17 +00:00
|
|
|
/*
|
|
|
|
* Called after parse_early_param(), after early parameters (such as mem=)
|
|
|
|
* have been processed, in which case we already have an E820 table filled in
|
|
|
|
* via the parameter callback function(s), but it's not sorted and printed yet:
|
|
|
|
*/
|
|
|
|
void __init e820__finish_early_params(void)
|
2008-06-10 19:55:54 +00:00
|
|
|
{
|
|
|
|
if (userdef) {
|
2017-01-28 13:09:20 +00:00
|
|
|
if (e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries) < 0)
|
2008-06-10 19:55:54 +00:00
|
|
|
early_panic("Invalid user supplied memory map");
|
|
|
|
|
2017-01-28 11:27:45 +00:00
|
|
|
pr_info("e820: user-defined physical RAM map:\n");
|
2017-01-28 13:24:02 +00:00
|
|
|
e820__print_table("user");
|
2008-06-10 19:55:54 +00:00
|
|
|
}
|
|
|
|
}
|
2008-06-16 20:03:31 +00:00
|
|
|
|
2017-01-28 13:33:48 +00:00
|
|
|
static const char *__init e820_type_to_string(struct e820_entry *entry)
|
2008-06-27 11:12:55 +00:00
|
|
|
{
|
2017-01-28 13:33:48 +00:00
|
|
|
switch (entry->type) {
|
2017-01-28 10:13:08 +00:00
|
|
|
case E820_RESERVED_KERN: /* Fall-through: */
|
|
|
|
case E820_RAM: return "System RAM";
|
|
|
|
case E820_ACPI: return "ACPI Tables";
|
|
|
|
case E820_NVS: return "ACPI Non-volatile Storage";
|
|
|
|
case E820_UNUSABLE: return "Unusable memory";
|
|
|
|
case E820_PRAM: return "Persistent Memory (legacy)";
|
|
|
|
case E820_PMEM: return "Persistent Memory";
|
|
|
|
default: return "Reserved";
|
2008-06-27 11:12:55 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-01-28 13:33:48 +00:00
|
|
|
static unsigned long __init e820_type_to_iomem_type(struct e820_entry *entry)
|
2016-01-26 20:57:20 +00:00
|
|
|
{
|
2017-01-28 13:33:48 +00:00
|
|
|
switch (entry->type) {
|
2017-01-28 10:13:08 +00:00
|
|
|
case E820_RESERVED_KERN: /* Fall-through: */
|
|
|
|
case E820_RAM: return IORESOURCE_SYSTEM_RAM;
|
|
|
|
case E820_ACPI: /* Fall-through: */
|
|
|
|
case E820_NVS: /* Fall-through: */
|
|
|
|
case E820_UNUSABLE: /* Fall-through: */
|
|
|
|
case E820_PRAM: /* Fall-through: */
|
|
|
|
case E820_PMEM: /* Fall-through: */
|
|
|
|
default: return IORESOURCE_MEM;
|
2016-01-26 20:57:20 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-01-28 13:33:48 +00:00
|
|
|
static unsigned long __init e820_type_to_iores_desc(struct e820_entry *entry)
|
2016-01-26 20:57:20 +00:00
|
|
|
{
|
2017-01-28 13:33:48 +00:00
|
|
|
switch (entry->type) {
|
2017-01-28 10:13:08 +00:00
|
|
|
case E820_ACPI: return IORES_DESC_ACPI_TABLES;
|
|
|
|
case E820_NVS: return IORES_DESC_ACPI_NV_STORAGE;
|
|
|
|
case E820_PMEM: return IORES_DESC_PERSISTENT_MEMORY;
|
|
|
|
case E820_PRAM: return IORES_DESC_PERSISTENT_MEMORY_LEGACY;
|
|
|
|
case E820_RESERVED_KERN: /* Fall-through: */
|
|
|
|
case E820_RAM: /* Fall-through: */
|
|
|
|
case E820_UNUSABLE: /* Fall-through: */
|
|
|
|
default: return IORES_DESC_NONE;
|
2016-01-26 20:57:20 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-09-17 21:39:25 +00:00
|
|
|
static bool __init do_mark_busy(u32 type, struct resource *res)
|
2015-04-03 16:05:28 +00:00
|
|
|
{
|
|
|
|
/* this is the legacy bios/dos rom-shadow + mmio region */
|
|
|
|
if (res->start < (1ULL<<20))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Treat persistent memory like device memory, i.e. reserve it
|
|
|
|
* for exclusive use of a driver
|
|
|
|
*/
|
|
|
|
switch (type) {
|
|
|
|
case E820_RESERVED:
|
|
|
|
case E820_PRAM:
|
|
|
|
case E820_PMEM:
|
|
|
|
return false;
|
|
|
|
default:
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-06-16 20:03:31 +00:00
|
|
|
/*
|
2017-01-28 10:13:08 +00:00
|
|
|
* Mark E820 reserved areas as busy for the resource manager:
|
2008-06-16 20:03:31 +00:00
|
|
|
*/
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2008-08-29 06:09:23 +00:00
|
|
|
static struct resource __initdata *e820_res;
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2008-06-16 20:03:31 +00:00
|
|
|
void __init e820_reserve_resources(void)
|
|
|
|
{
|
|
|
|
int i;
|
2008-08-28 20:52:25 +00:00
|
|
|
struct resource *res;
|
2008-08-29 06:09:23 +00:00
|
|
|
u64 end;
|
2008-06-16 20:03:31 +00:00
|
|
|
|
2017-01-28 13:33:48 +00:00
|
|
|
res = alloc_bootmem(sizeof(*res) * e820_table->nr_entries);
|
2008-08-28 20:52:25 +00:00
|
|
|
e820_res = res;
|
2017-01-28 13:33:48 +00:00
|
|
|
|
2017-01-27 13:06:21 +00:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
2017-01-28 13:33:48 +00:00
|
|
|
struct e820_entry *entry = e820_table->entries + i;
|
|
|
|
|
|
|
|
end = entry->addr + entry->size - 1;
|
2008-09-11 08:31:50 +00:00
|
|
|
if (end != (resource_size_t)end) {
|
2008-06-16 20:03:31 +00:00
|
|
|
res++;
|
|
|
|
continue;
|
|
|
|
}
|
2017-01-28 13:33:48 +00:00
|
|
|
res->start = entry->addr;
|
|
|
|
res->end = end;
|
|
|
|
res->name = e820_type_to_string(entry);
|
|
|
|
res->flags = e820_type_to_iomem_type(entry);
|
|
|
|
res->desc = e820_type_to_iores_desc(entry);
|
2008-08-29 06:09:23 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* don't register the region that could be conflicted with
|
|
|
|
* pci device BAR resource and insert them later in
|
|
|
|
* pcibios_resource_survey()
|
|
|
|
*/
|
2017-01-28 13:33:48 +00:00
|
|
|
if (do_mark_busy(entry->type, res)) {
|
x86: Clean up late e820 resource allocation
This makes the late e820 resources use 'insert_resource_expand_to_fit()'
instead of doing a 'reserve_region_with_split()', and also avoids
marking them as IORESOURCE_BUSY.
This results in us being perfectly happy to use pre-existing PCI
resources even if they were marked as being in a reserved region, while
still avoiding any _new_ allocations in the reserved regions. It also
makes for a simpler and more accurate resource tree.
Example resource allocation from Jonathan Corbet, who has firmware that
has an e820 reserved entry that covered a big range (e0000000-fed003ff),
and that had various PCI resources in it set up by firmware.
With old kernels, the reserved range would force us to re-allocate all
pre-existing PCI resources, and his reserved range would end up looking
like this:
e0000000-fed003ff : reserved
fec00000-fec00fff : IOAPIC 0
fed00000-fed003ff : HPET 0
where only the pre-allocated special regions (IOAPIC and HPET) were kept
around.
With 2.6.28-rc2, which uses 'reserve_region_with_split()', Jonathan's
resource tree looked like this:
e0000000-fe7fffff : reserved
fe800000-fe8fffff : PCI Bus 0000:01
fe800000-fe8fffff : reserved
fe900000-fe9d9aff : reserved
fe9d9b00-fe9d9bff : 0000:00:1f.3
fe9d9b00-fe9d9bff : reserved
fe9d9c00-fe9d9fff : 0000:00:1a.7
fe9d9c00-fe9d9fff : reserved
fe9da000-fe9dafff : 0000:00:03.3
fe9da000-fe9dafff : reserved
fe9db000-fe9dbfff : 0000:00:19.0
fe9db000-fe9dbfff : reserved
fe9dc000-fe9dffff : 0000:00:1b.0
fe9dc000-fe9dffff : reserved
fe9e0000-fe9fffff : 0000:00:19.0
fe9e0000-fe9fffff : reserved
fea00000-fea7ffff : 0000:00:02.0
fea00000-fea7ffff : reserved
fea80000-feafffff : 0000:00:02.1
fea80000-feafffff : reserved
feb00000-febfffff : 0000:00:02.0
feb00000-febfffff : reserved
fec00000-fed003ff : reserved
fec00000-fec00fff : IOAPIC 0
fed00000-fed003ff : HPET 0
and because the reserved entry had been split and moved into the
individual resources, and because it used the IORESOURCE_BUSY flag, the
drivers that actually wanted to _use_ those resources couldn't actually
attach to them:
e1000e 0000:00:19.0: BAR 0: can't reserve mem region [0xfe9e0000-0xfe9fffff]
HDA Intel 0000:00:1b.0: BAR 0: can't reserve mem region [0xfe9dc000-0xfe9dffff]
with this patch, the resource tree instead becomes
e0000000-fed003ff : reserved
fe800000-fe8fffff : PCI Bus 0000:01
fe9d9b00-fe9d9bff : 0000:00:1f.3
fe9d9c00-fe9d9fff : 0000:00:1a.7
fe9d9c00-fe9d9fff : ehci_hcd
fe9da000-fe9dafff : 0000:00:03.3
fe9db000-fe9dbfff : 0000:00:19.0
fe9db000-fe9dbfff : e1000e
fe9dc000-fe9dffff : 0000:00:1b.0
fe9dc000-fe9dffff : ICH HD audio
fe9e0000-fe9fffff : 0000:00:19.0
fe9e0000-fe9fffff : e1000e
fea00000-fea7ffff : 0000:00:02.0
fea80000-feafffff : 0000:00:02.1
feb00000-febfffff : 0000:00:02.0
fec00000-fec00fff : IOAPIC 0
fed00000-fed003ff : HPET 0
ie the one reserved region now ends up surrounding all the PCI resources
that were allocated inside of it by firmware, and because it is not
marked BUSY, drivers have no problem attaching to the pre-allocated
resources.
Reported-and-tested-by: Jonathan Corbet <corbet@lwn.net>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Robert Hancock <hancockr@shaw.ca>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-11-01 17:17:22 +00:00
|
|
|
res->flags |= IORESOURCE_BUSY;
|
2008-08-28 20:52:25 +00:00
|
|
|
insert_resource(&iomem_resource, res);
|
x86: Clean up late e820 resource allocation
This makes the late e820 resources use 'insert_resource_expand_to_fit()'
instead of doing a 'reserve_region_with_split()', and also avoids
marking them as IORESOURCE_BUSY.
This results in us being perfectly happy to use pre-existing PCI
resources even if they were marked as being in a reserved region, while
still avoiding any _new_ allocations in the reserved regions. It also
makes for a simpler and more accurate resource tree.
Example resource allocation from Jonathan Corbet, who has firmware that
has an e820 reserved entry that covered a big range (e0000000-fed003ff),
and that had various PCI resources in it set up by firmware.
With old kernels, the reserved range would force us to re-allocate all
pre-existing PCI resources, and his reserved range would end up looking
like this:
e0000000-fed003ff : reserved
fec00000-fec00fff : IOAPIC 0
fed00000-fed003ff : HPET 0
where only the pre-allocated special regions (IOAPIC and HPET) were kept
around.
With 2.6.28-rc2, which uses 'reserve_region_with_split()', Jonathan's
resource tree looked like this:
e0000000-fe7fffff : reserved
fe800000-fe8fffff : PCI Bus 0000:01
fe800000-fe8fffff : reserved
fe900000-fe9d9aff : reserved
fe9d9b00-fe9d9bff : 0000:00:1f.3
fe9d9b00-fe9d9bff : reserved
fe9d9c00-fe9d9fff : 0000:00:1a.7
fe9d9c00-fe9d9fff : reserved
fe9da000-fe9dafff : 0000:00:03.3
fe9da000-fe9dafff : reserved
fe9db000-fe9dbfff : 0000:00:19.0
fe9db000-fe9dbfff : reserved
fe9dc000-fe9dffff : 0000:00:1b.0
fe9dc000-fe9dffff : reserved
fe9e0000-fe9fffff : 0000:00:19.0
fe9e0000-fe9fffff : reserved
fea00000-fea7ffff : 0000:00:02.0
fea00000-fea7ffff : reserved
fea80000-feafffff : 0000:00:02.1
fea80000-feafffff : reserved
feb00000-febfffff : 0000:00:02.0
feb00000-febfffff : reserved
fec00000-fed003ff : reserved
fec00000-fec00fff : IOAPIC 0
fed00000-fed003ff : HPET 0
and because the reserved entry had been split and moved into the
individual resources, and because it used the IORESOURCE_BUSY flag, the
drivers that actually wanted to _use_ those resources couldn't actually
attach to them:
e1000e 0000:00:19.0: BAR 0: can't reserve mem region [0xfe9e0000-0xfe9fffff]
HDA Intel 0000:00:1b.0: BAR 0: can't reserve mem region [0xfe9dc000-0xfe9dffff]
with this patch, the resource tree instead becomes
e0000000-fed003ff : reserved
fe800000-fe8fffff : PCI Bus 0000:01
fe9d9b00-fe9d9bff : 0000:00:1f.3
fe9d9c00-fe9d9fff : 0000:00:1a.7
fe9d9c00-fe9d9fff : ehci_hcd
fe9da000-fe9dafff : 0000:00:03.3
fe9db000-fe9dbfff : 0000:00:19.0
fe9db000-fe9dbfff : e1000e
fe9dc000-fe9dffff : 0000:00:1b.0
fe9dc000-fe9dffff : ICH HD audio
fe9e0000-fe9fffff : 0000:00:19.0
fe9e0000-fe9fffff : e1000e
fea00000-fea7ffff : 0000:00:02.0
fea80000-feafffff : 0000:00:02.1
feb00000-febfffff : 0000:00:02.0
fec00000-fec00fff : IOAPIC 0
fed00000-fed003ff : HPET 0
ie the one reserved region now ends up surrounding all the PCI resources
that were allocated inside of it by firmware, and because it is not
marked BUSY, drivers have no problem attaching to the pre-allocated
resources.
Reported-and-tested-by: Jonathan Corbet <corbet@lwn.net>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Robert Hancock <hancockr@shaw.ca>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-11-01 17:17:22 +00:00
|
|
|
}
|
2008-06-16 20:03:31 +00:00
|
|
|
res++;
|
|
|
|
}
|
2008-06-27 11:12:55 +00:00
|
|
|
|
2017-01-28 09:07:49 +00:00
|
|
|
for (i = 0; i < e820_table_firmware->nr_entries; i++) {
|
2017-01-28 13:33:48 +00:00
|
|
|
struct e820_entry *entry = e820_table_firmware->entries + i;
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2017-01-28 13:33:48 +00:00
|
|
|
firmware_map_add_early(entry->addr, entry->addr + entry->size, e820_type_to_string(entry));
|
2008-06-27 11:12:55 +00:00
|
|
|
}
|
2008-06-16 20:03:31 +00:00
|
|
|
}
|
|
|
|
|
2009-05-06 15:06:44 +00:00
|
|
|
/* How much should we pad RAM ending depending on where it is? */
|
2016-09-17 21:39:25 +00:00
|
|
|
static unsigned long __init ram_alignment(resource_size_t pos)
|
2009-05-06 15:06:44 +00:00
|
|
|
{
|
|
|
|
unsigned long mb = pos >> 20;
|
|
|
|
|
|
|
|
/* To 64kB in the first megabyte */
|
|
|
|
if (!mb)
|
|
|
|
return 64*1024;
|
|
|
|
|
|
|
|
/* To 1MB in the first 16MB */
|
|
|
|
if (mb < 16)
|
|
|
|
return 1024*1024;
|
|
|
|
|
2009-10-11 21:17:16 +00:00
|
|
|
/* To 64MB for anything above that */
|
|
|
|
return 64*1024*1024;
|
2009-05-06 15:06:44 +00:00
|
|
|
}
|
|
|
|
|
2009-07-01 19:32:18 +00:00
|
|
|
#define MAX_RESOURCE_SIZE ((resource_size_t)-1)
|
|
|
|
|
2008-08-28 20:52:25 +00:00
|
|
|
void __init e820_reserve_resources_late(void)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
struct resource *res;
|
|
|
|
|
|
|
|
res = e820_res;
|
2017-01-27 13:06:21 +00:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
2008-08-29 06:09:23 +00:00
|
|
|
if (!res->parent && res->end)
|
x86: Clean up late e820 resource allocation
This makes the late e820 resources use 'insert_resource_expand_to_fit()'
instead of doing a 'reserve_region_with_split()', and also avoids
marking them as IORESOURCE_BUSY.
This results in us being perfectly happy to use pre-existing PCI
resources even if they were marked as being in a reserved region, while
still avoiding any _new_ allocations in the reserved regions. It also
makes for a simpler and more accurate resource tree.
Example resource allocation from Jonathan Corbet, who has firmware that
has an e820 reserved entry that covered a big range (e0000000-fed003ff),
and that had various PCI resources in it set up by firmware.
With old kernels, the reserved range would force us to re-allocate all
pre-existing PCI resources, and his reserved range would end up looking
like this:
e0000000-fed003ff : reserved
fec00000-fec00fff : IOAPIC 0
fed00000-fed003ff : HPET 0
where only the pre-allocated special regions (IOAPIC and HPET) were kept
around.
With 2.6.28-rc2, which uses 'reserve_region_with_split()', Jonathan's
resource tree looked like this:
e0000000-fe7fffff : reserved
fe800000-fe8fffff : PCI Bus 0000:01
fe800000-fe8fffff : reserved
fe900000-fe9d9aff : reserved
fe9d9b00-fe9d9bff : 0000:00:1f.3
fe9d9b00-fe9d9bff : reserved
fe9d9c00-fe9d9fff : 0000:00:1a.7
fe9d9c00-fe9d9fff : reserved
fe9da000-fe9dafff : 0000:00:03.3
fe9da000-fe9dafff : reserved
fe9db000-fe9dbfff : 0000:00:19.0
fe9db000-fe9dbfff : reserved
fe9dc000-fe9dffff : 0000:00:1b.0
fe9dc000-fe9dffff : reserved
fe9e0000-fe9fffff : 0000:00:19.0
fe9e0000-fe9fffff : reserved
fea00000-fea7ffff : 0000:00:02.0
fea00000-fea7ffff : reserved
fea80000-feafffff : 0000:00:02.1
fea80000-feafffff : reserved
feb00000-febfffff : 0000:00:02.0
feb00000-febfffff : reserved
fec00000-fed003ff : reserved
fec00000-fec00fff : IOAPIC 0
fed00000-fed003ff : HPET 0
and because the reserved entry had been split and moved into the
individual resources, and because it used the IORESOURCE_BUSY flag, the
drivers that actually wanted to _use_ those resources couldn't actually
attach to them:
e1000e 0000:00:19.0: BAR 0: can't reserve mem region [0xfe9e0000-0xfe9fffff]
HDA Intel 0000:00:1b.0: BAR 0: can't reserve mem region [0xfe9dc000-0xfe9dffff]
with this patch, the resource tree instead becomes
e0000000-fed003ff : reserved
fe800000-fe8fffff : PCI Bus 0000:01
fe9d9b00-fe9d9bff : 0000:00:1f.3
fe9d9c00-fe9d9fff : 0000:00:1a.7
fe9d9c00-fe9d9fff : ehci_hcd
fe9da000-fe9dafff : 0000:00:03.3
fe9db000-fe9dbfff : 0000:00:19.0
fe9db000-fe9dbfff : e1000e
fe9dc000-fe9dffff : 0000:00:1b.0
fe9dc000-fe9dffff : ICH HD audio
fe9e0000-fe9fffff : 0000:00:19.0
fe9e0000-fe9fffff : e1000e
fea00000-fea7ffff : 0000:00:02.0
fea80000-feafffff : 0000:00:02.1
feb00000-febfffff : 0000:00:02.0
fec00000-fec00fff : IOAPIC 0
fed00000-fed003ff : HPET 0
ie the one reserved region now ends up surrounding all the PCI resources
that were allocated inside of it by firmware, and because it is not
marked BUSY, drivers have no problem attaching to the pre-allocated
resources.
Reported-and-tested-by: Jonathan Corbet <corbet@lwn.net>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Robert Hancock <hancockr@shaw.ca>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-11-01 17:17:22 +00:00
|
|
|
insert_resource_expand_to_fit(&iomem_resource, res);
|
2008-08-28 20:52:25 +00:00
|
|
|
res++;
|
|
|
|
}
|
2009-05-06 15:06:44 +00:00
|
|
|
|
|
|
|
/*
|
2017-01-28 10:13:08 +00:00
|
|
|
* Try to bump up RAM regions to reasonable boundaries, to
|
2009-05-06 15:06:44 +00:00
|
|
|
* avoid stolen RAM:
|
|
|
|
*/
|
2017-01-27 13:06:21 +00:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
|
|
|
struct e820_entry *entry = &e820_table->entries[i];
|
2009-07-01 19:32:18 +00:00
|
|
|
u64 start, end;
|
2009-05-06 15:06:44 +00:00
|
|
|
|
|
|
|
if (entry->type != E820_RAM)
|
|
|
|
continue;
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2009-05-06 15:06:44 +00:00
|
|
|
start = entry->addr + entry->size;
|
2009-07-01 19:32:18 +00:00
|
|
|
end = round_up(start, ram_alignment(start)) - 1;
|
|
|
|
if (end > MAX_RESOURCE_SIZE)
|
|
|
|
end = MAX_RESOURCE_SIZE;
|
|
|
|
if (start >= end)
|
2009-05-06 15:06:44 +00:00
|
|
|
continue;
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2017-01-28 11:27:45 +00:00
|
|
|
pr_debug("e820: reserve RAM buffer [mem %#010llx-%#010llx]\n", start, end);
|
2017-01-28 10:13:08 +00:00
|
|
|
reserve_region_with_split(&iomem_resource, start, end, "RAM buffer");
|
2009-05-06 15:06:44 +00:00
|
|
|
}
|
2008-08-28 20:52:25 +00:00
|
|
|
}
|
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/*
|
|
|
|
* Pass the firmware (bootloader) E820 map to the kernel and process it:
|
|
|
|
*/
|
2017-01-28 08:58:49 +00:00
|
|
|
char *__init e820__memory_setup_default(void)
|
2008-06-17 02:58:28 +00:00
|
|
|
{
|
|
|
|
char *who = "BIOS-e820";
|
2009-03-22 20:43:01 +00:00
|
|
|
u32 new_nr;
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2008-06-17 02:58:28 +00:00
|
|
|
/*
|
|
|
|
* Try to copy the BIOS-supplied E820-map.
|
|
|
|
*
|
|
|
|
* Otherwise fake a memory map; one section from 0k->640k,
|
|
|
|
* the next section from 1mb->appropriate_mem_k
|
|
|
|
*/
|
|
|
|
new_nr = boot_params.e820_entries;
|
2017-01-28 13:09:20 +00:00
|
|
|
e820__update_table(boot_params.e820_table, ARRAY_SIZE(boot_params.e820_table), &new_nr);
|
2008-06-17 02:58:28 +00:00
|
|
|
boot_params.e820_entries = new_nr;
|
2017-01-28 10:13:08 +00:00
|
|
|
|
|
|
|
if (append_e820_table(boot_params.e820_table, boot_params.e820_entries) < 0) {
|
2008-06-19 00:27:08 +00:00
|
|
|
u64 mem_size;
|
2008-06-17 02:58:28 +00:00
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/* Compare results from other methods and take the one that gives more RAM: */
|
|
|
|
if (boot_params.alt_mem_k < boot_params.screen_info.ext_mem_k) {
|
2008-06-17 02:58:28 +00:00
|
|
|
mem_size = boot_params.screen_info.ext_mem_k;
|
|
|
|
who = "BIOS-88";
|
|
|
|
} else {
|
|
|
|
mem_size = boot_params.alt_mem_k;
|
|
|
|
who = "BIOS-e801";
|
|
|
|
}
|
|
|
|
|
2017-01-27 13:06:21 +00:00
|
|
|
e820_table->nr_entries = 0;
|
x86/boot/e820: Create coherent API function names for E820 range operations
We have these three related functions:
extern void e820_add_region(u64 start, u64 size, int type);
extern u64 e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);
But it's not clear from the naming that they are 3 operations based around the
same 'memory range' concept. Rename them to better signal this, and move
the prototypes next to each other:
extern void e820__range_add (u64 start, u64 size, int type);
extern u64 e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);
Note that this improved organization of the functions shows another problem that was easy
to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
will be fixed in a separate patch.
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 13:19:36 +00:00
|
|
|
e820__range_add(0, LOWMEMSIZE(), E820_RAM);
|
|
|
|
e820__range_add(HIGH_MEMORY, mem_size << 10, E820_RAM);
|
2008-06-17 02:58:28 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return who;
|
|
|
|
}
|
|
|
|
|
2017-01-28 08:58:49 +00:00
|
|
|
/*
|
|
|
|
* Calls e820__memory_setup_default() in essence to pick up the firmware/bootloader
|
|
|
|
* E820 map - with an optional platform quirk available for virtual platforms
|
|
|
|
* to override this method of boot environment processing:
|
|
|
|
*/
|
|
|
|
void __init e820__memory_setup(void)
|
2008-06-17 02:58:28 +00:00
|
|
|
{
|
2008-07-03 18:35:37 +00:00
|
|
|
char *who;
|
|
|
|
|
2009-08-20 08:19:54 +00:00
|
|
|
who = x86_init.resources.memory_setup();
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2017-01-28 09:07:49 +00:00
|
|
|
memcpy(e820_table_firmware, e820_table, sizeof(struct e820_table));
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2017-01-28 11:27:45 +00:00
|
|
|
pr_info("e820: BIOS-provided physical RAM map:\n");
|
2017-01-28 13:24:02 +00:00
|
|
|
e820__print_table(who);
|
2008-06-17 02:58:28 +00:00
|
|
|
}
|
2010-08-25 20:39:17 +00:00
|
|
|
|
x86/boot/e820: Rename memblock_x86_fill() to e820__memblock_setup() and improve the explanations
So memblock_x86_fill() is another E820 code misnomer:
- nothing in its name tells us that it's part of the E820 subsystem ...
- The 'fill' wording is ambiguous and doesn't tell us whether it's a single
entry or some process - while the _real_ purpose of the function is hidden,
which is to do a complete setup of the (platform independent) memblock regions.
So rename it accordingly, to e820__memblock_setup().
Also translate this incomprehensible and misleading comment:
/*
* EFI may have more than 128 entries
* We are safe to enable resizing, beause memblock_x86_fill()
* is rather later for x86
*/
memblock_allow_resize();
The worst aspect of this comment isn't even the sloppy typos, but that it
casually mentions a '128' number with no explanation, which makes one lead
to the assumption that this is related to the well-known limit of a maximum
of 128 E820 entries passed via legacy bootloaders.
But no, the _real_ meaning of 128 here is that of the memblock subsystem,
which too happens to have a 128 entries limit for very early memblock
regions (which is unrelated to E820), via INIT_MEMBLOCK_REGIONS ...
So change the comment to a more comprehensible version:
/*
* The bootstrap memblock region count maximum is 128 entries
* (INIT_MEMBLOCK_REGIONS), but EFI might pass us more E820 entries
* than that - so allow memblock resizing.
*
* This is safe, because this call happens pretty late during x86 setup,
* so we know about reserved memory regions already. (This is important
* so that memblock resizing does no stomp over reserved areas.)
*/
memblock_allow_resize();
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 10:37:42 +00:00
|
|
|
void __init e820__memblock_setup(void)
|
2010-08-25 20:39:17 +00:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
u64 end;
|
|
|
|
|
|
|
|
/*
|
x86/boot/e820: Rename memblock_x86_fill() to e820__memblock_setup() and improve the explanations
So memblock_x86_fill() is another E820 code misnomer:
- nothing in its name tells us that it's part of the E820 subsystem ...
- The 'fill' wording is ambiguous and doesn't tell us whether it's a single
entry or some process - while the _real_ purpose of the function is hidden,
which is to do a complete setup of the (platform independent) memblock regions.
So rename it accordingly, to e820__memblock_setup().
Also translate this incomprehensible and misleading comment:
/*
* EFI may have more than 128 entries
* We are safe to enable resizing, beause memblock_x86_fill()
* is rather later for x86
*/
memblock_allow_resize();
The worst aspect of this comment isn't even the sloppy typos, but that it
casually mentions a '128' number with no explanation, which makes one lead
to the assumption that this is related to the well-known limit of a maximum
of 128 E820 entries passed via legacy bootloaders.
But no, the _real_ meaning of 128 here is that of the memblock subsystem,
which too happens to have a 128 entries limit for very early memblock
regions (which is unrelated to E820), via INIT_MEMBLOCK_REGIONS ...
So change the comment to a more comprehensible version:
/*
* The bootstrap memblock region count maximum is 128 entries
* (INIT_MEMBLOCK_REGIONS), but EFI might pass us more E820 entries
* than that - so allow memblock resizing.
*
* This is safe, because this call happens pretty late during x86 setup,
* so we know about reserved memory regions already. (This is important
* so that memblock resizing does no stomp over reserved areas.)
*/
memblock_allow_resize();
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 10:37:42 +00:00
|
|
|
* The bootstrap memblock region count maximum is 128 entries
|
|
|
|
* (INIT_MEMBLOCK_REGIONS), but EFI might pass us more E820 entries
|
|
|
|
* than that - so allow memblock resizing.
|
|
|
|
*
|
|
|
|
* This is safe, because this call happens pretty late during x86 setup,
|
|
|
|
* so we know about reserved memory regions already. (This is important
|
|
|
|
* so that memblock resizing does no stomp over reserved areas.)
|
2010-08-25 20:39:17 +00:00
|
|
|
*/
|
2011-12-08 18:22:08 +00:00
|
|
|
memblock_allow_resize();
|
2010-08-25 20:39:17 +00:00
|
|
|
|
2017-01-27 13:06:21 +00:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
2017-01-28 11:16:17 +00:00
|
|
|
struct e820_entry *entry = &e820_table->entries[i];
|
2010-08-25 20:39:17 +00:00
|
|
|
|
2017-01-28 11:16:17 +00:00
|
|
|
end = entry->addr + entry->size;
|
2010-08-25 20:39:17 +00:00
|
|
|
if (end != (resource_size_t)end)
|
|
|
|
continue;
|
|
|
|
|
2017-01-28 11:16:17 +00:00
|
|
|
if (entry->type != E820_RAM && entry->type != E820_RESERVED_KERN)
|
2010-08-25 20:39:17 +00:00
|
|
|
continue;
|
|
|
|
|
2017-01-28 11:16:17 +00:00
|
|
|
memblock_add(entry->addr, entry->size);
|
2010-08-25 20:39:17 +00:00
|
|
|
}
|
|
|
|
|
x86/boot/e820: Rename memblock_x86_fill() to e820__memblock_setup() and improve the explanations
So memblock_x86_fill() is another E820 code misnomer:
- nothing in its name tells us that it's part of the E820 subsystem ...
- The 'fill' wording is ambiguous and doesn't tell us whether it's a single
entry or some process - while the _real_ purpose of the function is hidden,
which is to do a complete setup of the (platform independent) memblock regions.
So rename it accordingly, to e820__memblock_setup().
Also translate this incomprehensible and misleading comment:
/*
* EFI may have more than 128 entries
* We are safe to enable resizing, beause memblock_x86_fill()
* is rather later for x86
*/
memblock_allow_resize();
The worst aspect of this comment isn't even the sloppy typos, but that it
casually mentions a '128' number with no explanation, which makes one lead
to the assumption that this is related to the well-known limit of a maximum
of 128 E820 entries passed via legacy bootloaders.
But no, the _real_ meaning of 128 here is that of the memblock subsystem,
which too happens to have a 128 entries limit for very early memblock
regions (which is unrelated to E820), via INIT_MEMBLOCK_REGIONS ...
So change the comment to a more comprehensible version:
/*
* The bootstrap memblock region count maximum is 128 entries
* (INIT_MEMBLOCK_REGIONS), but EFI might pass us more E820 entries
* than that - so allow memblock resizing.
*
* This is safe, because this call happens pretty late during x86 setup,
* so we know about reserved memory regions already. (This is important
* so that memblock resizing does no stomp over reserved areas.)
*/
memblock_allow_resize();
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 10:37:42 +00:00
|
|
|
/* Throw away partial pages: */
|
2012-10-22 23:35:18 +00:00
|
|
|
memblock_trim_memory(PAGE_SIZE);
|
|
|
|
|
2010-08-25 20:39:17 +00:00
|
|
|
memblock_dump_all();
|
|
|
|
}
|