2008-05-11 15:30:15 +08:00
|
|
|
/*
|
2017-01-28 18:13:08 +08:00
|
|
|
* Low level x86 E820 memory map handling functions.
|
2008-05-11 15:30:15 +08:00
|
|
|
*
|
2017-01-28 18:13:08 +08: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 15:30:15 +08:00
|
|
|
*
|
2017-01-28 18:13:08 +08: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 15:30:15 +08:00
|
|
|
*/
|
2011-03-24 07:43:29 +08:00
|
|
|
#include <linux/crash_dump.h>
|
2008-05-11 15:30:15 +08:00
|
|
|
#include <linux/bootmem.h>
|
2008-05-21 11:10:58 +08:00
|
|
|
#include <linux/suspend.h>
|
2011-01-07 08:43:44 +08:00
|
|
|
#include <linux/acpi.h>
|
2008-06-27 19:12:55 +08:00
|
|
|
#include <linux/firmware-map.h>
|
2010-08-26 04:39:17 +08:00
|
|
|
#include <linux/memblock.h>
|
2011-11-16 06:46:50 +08:00
|
|
|
#include <linux/sort.h>
|
2008-05-11 15:30:15 +08:00
|
|
|
|
2017-01-27 17:27:10 +08:00
|
|
|
#include <asm/e820/api.h>
|
2008-05-11 15:30:15 +08:00
|
|
|
#include <asm/setup.h>
|
|
|
|
|
2008-06-27 19:12:55 +08:00
|
|
|
/*
|
2017-07-03 01:07:32 +08:00
|
|
|
* We organize the E820 table into three main data structures:
|
2017-01-28 17:07:49 +08:00
|
|
|
*
|
2017-07-03 01:07:32 +08:00
|
|
|
* - 'e820_table_firmware': the original firmware version passed to us by the
|
|
|
|
* bootloader - not modified by the kernel. It is composed of two parts:
|
|
|
|
* the first 128 E820 memory entries in boot_params.e820_table and the remaining
|
|
|
|
* (if any) entries of the SETUP_E820_EXT nodes. We use this to:
|
2017-01-28 17:07:49 +08:00
|
|
|
*
|
|
|
|
* - 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-07-03 01:07:32 +08:00
|
|
|
* - 'e820_table_kexec': a slightly modified (by the kernel) firmware version
|
|
|
|
* passed to us by the bootloader - the major difference between
|
|
|
|
* e820_table_firmware[] and this one is that, the latter marks the setup_data
|
|
|
|
* list created by the EFI boot stub as reserved, so that kexec can reuse the
|
|
|
|
* setup_data information in the second kernel. Besides, e820_table_kexec[]
|
|
|
|
* might also be modified by the kexec itself to fake a mptable.
|
|
|
|
* We use this to:
|
|
|
|
*
|
2017-01-28 18:13:08 +08:00
|
|
|
* - kexec, which is a bootloader in disguise, uses the original E820
|
2017-01-28 17:07:49 +08:00
|
|
|
* layout to pass to the kexec-ed kernel. This way the original kernel
|
2017-01-28 18:13:08 +08:00
|
|
|
* can have a restricted E820 map while the kexec()-ed kexec-kernel
|
2017-01-28 17:07:49 +08:00
|
|
|
* can have access to full memory - etc.
|
|
|
|
*
|
2017-01-28 18:13:08 +08:00
|
|
|
* - 'e820_table': this is the main E820 table that is massaged by the
|
2017-01-28 17:07:49 +08:00
|
|
|
* low level x86 platform code, or modified by boot parameters, before
|
|
|
|
* passed on to higher level MM layers.
|
|
|
|
*
|
2017-01-28 18:13:08 +08:00
|
|
|
* Once the E820 map has been converted to the standard Linux memory layout
|
2017-01-28 17:07:49 +08: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 19:12:55 +08:00
|
|
|
*/
|
2017-01-28 17:07:49 +08:00
|
|
|
static struct e820_table e820_table_init __initdata;
|
2017-07-03 01:07:12 +08:00
|
|
|
static struct e820_table e820_table_kexec_init __initdata;
|
2017-07-03 01:07:32 +08:00
|
|
|
static struct e820_table e820_table_firmware_init __initdata;
|
2017-01-28 17:07:49 +08:00
|
|
|
|
|
|
|
struct e820_table *e820_table __refdata = &e820_table_init;
|
2017-07-03 01:07:12 +08:00
|
|
|
struct e820_table *e820_table_kexec __refdata = &e820_table_kexec_init;
|
2017-07-03 01:07:32 +08:00
|
|
|
struct e820_table *e820_table_firmware __refdata = &e820_table_firmware_init;
|
2008-05-11 15:30:15 +08: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-29 05:34:55 +08:00
|
|
|
bool e820__mapped_any(u64 start, u64 end, enum e820_type type)
|
2008-05-11 15:30:15 +08:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2017-01-27 21:06:21 +08:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
2017-01-28 19:16:17 +08:00
|
|
|
struct e820_entry *entry = &e820_table->entries[i];
|
2008-05-11 15:30:15 +08:00
|
|
|
|
2017-01-28 19:16:17 +08:00
|
|
|
if (type && entry->type != type)
|
2008-05-11 15:30:15 +08:00
|
|
|
continue;
|
2017-01-28 19:16:17 +08:00
|
|
|
if (entry->addr >= end || entry->addr + entry->size <= start)
|
2008-05-11 15:30:15 +08:00
|
|
|
continue;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
2017-01-28 21:14:25 +08:00
|
|
|
EXPORT_SYMBOL_GPL(e820__mapped_any);
|
2008-05-11 15:30:15 +08:00
|
|
|
|
|
|
|
/*
|
2017-01-28 18:13:08 +08:00
|
|
|
* This function checks if the entire <start,end> range is mapped with 'type'.
|
2008-05-11 15:30:15 +08:00
|
|
|
*
|
2017-01-28 18:13:08 +08: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 15:30:15 +08:00
|
|
|
*/
|
2017-07-18 05:10:12 +08:00
|
|
|
static struct e820_entry *__e820__mapped_all(u64 start, u64 end,
|
|
|
|
enum e820_type type)
|
2008-05-11 15:30:15 +08:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2017-01-27 21:06:21 +08:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
2017-01-28 19:16:17 +08:00
|
|
|
struct e820_entry *entry = &e820_table->entries[i];
|
2008-05-11 15:30:15 +08:00
|
|
|
|
2017-01-28 19:16:17 +08:00
|
|
|
if (type && entry->type != type)
|
2008-05-11 15:30:15 +08:00
|
|
|
continue;
|
2017-01-28 18:13:08 +08:00
|
|
|
|
|
|
|
/* Is the region (part) in overlap with the current region? */
|
2017-01-28 19:16:17 +08:00
|
|
|
if (entry->addr >= end || entry->addr + entry->size <= start)
|
2008-05-11 15:30:15 +08:00
|
|
|
continue;
|
|
|
|
|
2017-01-28 18:13:08 +08: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 15:30:15 +08:00
|
|
|
*/
|
2017-01-28 19:16:17 +08:00
|
|
|
if (entry->addr <= start)
|
|
|
|
start = entry->addr + entry->size;
|
2017-01-28 18:13:08 +08:00
|
|
|
|
2008-05-11 15:30:15 +08:00
|
|
|
/*
|
2017-01-28 18:13:08 +08:00
|
|
|
* If 'start' is now at or beyond 'end', we're done, full
|
|
|
|
* coverage of the desired range exists:
|
2008-05-11 15:30:15 +08:00
|
|
|
*/
|
|
|
|
if (start >= end)
|
2017-07-18 05:10:12 +08:00
|
|
|
return entry;
|
2008-05-11 15:30:15 +08:00
|
|
|
}
|
2017-07-18 05:10:12 +08:00
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This function checks if the entire range <start,end> is mapped with type.
|
|
|
|
*/
|
|
|
|
bool __init e820__mapped_all(u64 start, u64 end, enum e820_type type)
|
|
|
|
{
|
|
|
|
return __e820__mapped_all(start, end, type);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This function returns the type associated with the range <start,end>.
|
|
|
|
*/
|
|
|
|
int e820__get_entry_type(u64 start, u64 end)
|
|
|
|
{
|
|
|
|
struct e820_entry *entry = __e820__mapped_all(start, end, 0);
|
|
|
|
|
|
|
|
return entry ? entry->type : -EINVAL;
|
2008-05-11 15:30:15 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2017-01-28 18:13:08 +08:00
|
|
|
* Add a memory region to the kernel E820 map.
|
2008-05-11 15:30:15 +08:00
|
|
|
*/
|
2017-01-28 23:52:34 +08:00
|
|
|
static void __init __e820__range_add(struct e820_table *table, u64 start, u64 size, enum e820_type type)
|
2008-05-11 15:30:15 +08:00
|
|
|
{
|
2017-01-27 21:06:21 +08:00
|
|
|
int x = table->nr_entries;
|
2008-05-11 15:30:15 +08:00
|
|
|
|
2017-01-27 21:06:21 +08:00
|
|
|
if (x >= ARRAY_SIZE(table->entries)) {
|
2018-05-10 23:45:30 +08:00
|
|
|
pr_err("too many entries; ignoring [mem %#010llx-%#010llx]\n",
|
|
|
|
start, start + size - 1);
|
2008-05-11 15:30:15 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2017-01-27 21:06:21 +08:00
|
|
|
table->entries[x].addr = start;
|
|
|
|
table->entries[x].size = size;
|
|
|
|
table->entries[x].type = type;
|
|
|
|
table->nr_entries++;
|
2009-03-13 12:35:18 +08:00
|
|
|
}
|
|
|
|
|
2017-01-28 23:52:34 +08:00
|
|
|
void __init e820__range_add(u64 start, u64 size, enum e820_type type)
|
2009-03-13 12:35:18 +08: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 21:19:36 +08:00
|
|
|
__e820__range_add(e820_table, start, size, type);
|
2008-05-11 15:30:15 +08:00
|
|
|
}
|
|
|
|
|
2017-01-28 23:52:34 +08:00
|
|
|
static void __init e820_print_type(enum e820_type type)
|
2009-03-15 15:59:19 +08:00
|
|
|
{
|
|
|
|
switch (type) {
|
2017-01-29 00:09:33 +08:00
|
|
|
case E820_TYPE_RAM: /* Fall through: */
|
|
|
|
case E820_TYPE_RESERVED_KERN: pr_cont("usable"); break;
|
|
|
|
case E820_TYPE_RESERVED: pr_cont("reserved"); break;
|
|
|
|
case E820_TYPE_ACPI: pr_cont("ACPI data"); break;
|
|
|
|
case E820_TYPE_NVS: pr_cont("ACPI NVS"); break;
|
|
|
|
case E820_TYPE_UNUSABLE: pr_cont("unusable"); break;
|
|
|
|
case E820_TYPE_PMEM: /* Fall through: */
|
|
|
|
case E820_TYPE_PRAM: pr_cont("persistent (type %u)", type); break;
|
2017-01-28 19:27:45 +08:00
|
|
|
default: pr_cont("type %u", type); break;
|
2009-03-15 15:59:19 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-01-28 21:24:02 +08:00
|
|
|
void __init e820__print_table(char *who)
|
2008-05-11 15:30:15 +08:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2017-01-27 21:06:21 +08:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
2018-05-10 23:45:30 +08:00
|
|
|
pr_info("%s: [mem %#018Lx-%#018Lx] ",
|
|
|
|
who,
|
|
|
|
e820_table->entries[i].addr,
|
|
|
|
e820_table->entries[i].addr + e820_table->entries[i].size - 1);
|
2017-01-28 18:13:08 +08:00
|
|
|
|
2017-01-27 21:06:21 +08:00
|
|
|
e820_print_type(e820_table->entries[i].type);
|
2017-01-28 19:27:45 +08:00
|
|
|
pr_cont("\n");
|
2008-05-11 15:30:15 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2017-01-29 01:35:24 +08:00
|
|
|
* Sanitize an E820 map.
|
2008-05-11 15:30:15 +08:00
|
|
|
*
|
2017-01-29 01:35:24 +08:00
|
|
|
* Some E820 layouts include overlapping entries. The following
|
2017-01-28 18:13:08 +08:00
|
|
|
* replaces the original E820 map with a new one, removing overlaps,
|
2008-05-14 23:15:52 +08:00
|
|
|
* and resolving conflicting memory types in favor of highest
|
|
|
|
* numbered type.
|
2008-05-11 15:30:15 +08:00
|
|
|
*
|
2017-01-29 01:35:24 +08:00
|
|
|
* The input parameter 'entries' points to an array of 'struct
|
|
|
|
* e820_entry' which on entry has elements in the range [0, *nr_entries)
|
|
|
|
* valid, and which has space for up to max_nr_entries entries.
|
2017-01-28 18:13:08 +08:00
|
|
|
* On return, the resulting sanitized E820 map entries will be in
|
2017-01-29 01:35:24 +08:00
|
|
|
* overwritten in the same location, starting at 'entries'.
|
2008-05-14 23:15:52 +08:00
|
|
|
*
|
2017-01-29 01:35:24 +08:00
|
|
|
* The integer pointed to by nr_entries must be valid on entry (the
|
|
|
|
* current number of valid entries located at 'entries'). If the
|
|
|
|
* sanitizing succeeds the *nr_entries will be updated with the new
|
|
|
|
* number of valid entries (something no more than max_nr_entries).
|
2008-05-14 23:15:52 +08:00
|
|
|
*
|
2017-01-28 21:09:20 +08:00
|
|
|
* The return value from e820__update_table() is zero if it
|
2008-05-14 23:15:52 +08: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 15:30:15 +08:00
|
|
|
*/
|
2011-11-16 06:46:50 +08:00
|
|
|
struct change_member {
|
2017-01-29 01:35:24 +08:00
|
|
|
/* Pointer to the original entry: */
|
|
|
|
struct e820_entry *entry;
|
2017-01-28 18:13:08 +08:00
|
|
|
/* Address for this change point: */
|
|
|
|
unsigned long long addr;
|
2011-11-16 06:46:50 +08:00
|
|
|
};
|
|
|
|
|
2017-01-30 16:24:39 +08:00
|
|
|
static struct change_member change_point_list[2*E820_MAX_ENTRIES] __initdata;
|
|
|
|
static struct change_member *change_point[2*E820_MAX_ENTRIES] __initdata;
|
|
|
|
static struct e820_entry *overlap_list[E820_MAX_ENTRIES] __initdata;
|
|
|
|
static struct e820_entry new_entries[E820_MAX_ENTRIES] __initdata;
|
|
|
|
|
2011-11-16 06:46:50 +08: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 18:13:08 +08:00
|
|
|
* addresses are not equal, their difference dominates. If the addresses
|
2011-11-16 06:46:50 +08: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;
|
|
|
|
|
2017-01-29 01:35:24 +08:00
|
|
|
return (ap->addr != ap->entry->addr) - (bp->addr != bp->entry->addr);
|
2011-11-16 06:46:50 +08:00
|
|
|
}
|
2008-05-14 23:15:52 +08:00
|
|
|
|
2017-01-30 16:24:39 +08:00
|
|
|
int __init e820__update_table(struct e820_table *table)
|
2008-05-11 15:30:15 +08:00
|
|
|
{
|
2017-01-30 16:24:39 +08:00
|
|
|
struct e820_entry *entries = table->entries;
|
|
|
|
u32 max_nr_entries = ARRAY_SIZE(table->entries);
|
2017-01-28 23:52:34 +08:00
|
|
|
enum e820_type current_type, last_type;
|
2008-05-11 15:30:15 +08:00
|
|
|
unsigned long long last_addr;
|
2017-01-30 16:24:39 +08:00
|
|
|
u32 new_nr_entries, overlap_entries;
|
|
|
|
u32 i, chg_idx, chg_nr;
|
2008-05-11 15:30:15 +08:00
|
|
|
|
2017-01-28 18:13:08 +08:00
|
|
|
/* If there's only one memory region, don't bother: */
|
2017-01-30 16:24:39 +08:00
|
|
|
if (table->nr_entries < 2)
|
2008-05-11 15:30:15 +08:00
|
|
|
return -1;
|
|
|
|
|
2017-01-30 16:24:39 +08:00
|
|
|
BUG_ON(table->nr_entries > max_nr_entries);
|
2008-05-11 15:30:15 +08:00
|
|
|
|
2017-01-29 01:35:24 +08:00
|
|
|
/* Bail out if we find any unreasonable addresses in the map: */
|
2017-01-30 16:24:39 +08:00
|
|
|
for (i = 0; i < table->nr_entries; i++) {
|
2017-01-29 01:35:24 +08:00
|
|
|
if (entries[i].addr + entries[i].size < entries[i].addr)
|
2008-05-11 15:30:15 +08:00
|
|
|
return -1;
|
2017-01-28 18:13:08 +08:00
|
|
|
}
|
2008-05-11 15:30:15 +08:00
|
|
|
|
2017-01-28 18:13:08 +08:00
|
|
|
/* Create pointers for initial change-point information (for sorting): */
|
2017-01-30 16:24:39 +08:00
|
|
|
for (i = 0; i < 2 * table->nr_entries; i++)
|
2008-05-11 15:30:15 +08:00
|
|
|
change_point[i] = &change_point_list[i];
|
|
|
|
|
2017-01-28 18:13:08 +08:00
|
|
|
/*
|
|
|
|
* Record all known change-points (starting and ending addresses),
|
|
|
|
* omitting empty memory regions:
|
|
|
|
*/
|
2017-01-30 16:24:39 +08:00
|
|
|
chg_idx = 0;
|
|
|
|
for (i = 0; i < table->nr_entries; i++) {
|
2017-01-29 01:35:24 +08:00
|
|
|
if (entries[i].size != 0) {
|
2017-01-30 16:24:39 +08:00
|
|
|
change_point[chg_idx]->addr = entries[i].addr;
|
|
|
|
change_point[chg_idx++]->entry = &entries[i];
|
|
|
|
change_point[chg_idx]->addr = entries[i].addr + entries[i].size;
|
|
|
|
change_point[chg_idx++]->entry = &entries[i];
|
2008-05-11 15:30:15 +08:00
|
|
|
}
|
|
|
|
}
|
2017-01-30 16:24:39 +08:00
|
|
|
chg_nr = chg_idx;
|
2008-05-11 15:30:15 +08:00
|
|
|
|
2017-01-28 18:13:08 +08:00
|
|
|
/* Sort change-point list by memory addresses (low -> high): */
|
2017-01-29 00:48:08 +08:00
|
|
|
sort(change_point, chg_nr, sizeof(*change_point), cpcompare, NULL);
|
2008-05-11 15:30:15 +08:00
|
|
|
|
2017-01-29 01:35:24 +08:00
|
|
|
/* Create a new memory map, removing overlaps: */
|
2017-01-28 18:13:08 +08:00
|
|
|
overlap_entries = 0; /* Number of entries in the overlap table */
|
2017-01-29 01:35:24 +08:00
|
|
|
new_nr_entries = 0; /* Index for creating new map entries */
|
2017-01-28 18:13:08 +08:00
|
|
|
last_type = 0; /* Start with undefined memory type */
|
|
|
|
last_addr = 0; /* Start with 0 as last starting address */
|
2008-05-11 15:30:15 +08:00
|
|
|
|
2017-01-29 01:35:24 +08:00
|
|
|
/* Loop through change-points, determining effect on the new map: */
|
2017-01-30 16:24:39 +08:00
|
|
|
for (chg_idx = 0; chg_idx < chg_nr; chg_idx++) {
|
2017-01-29 01:35:24 +08:00
|
|
|
/* Keep track of all overlapping entries */
|
2017-01-30 16:24:39 +08:00
|
|
|
if (change_point[chg_idx]->addr == change_point[chg_idx]->entry->addr) {
|
2017-01-28 18:13:08 +08:00
|
|
|
/* Add map entry to overlap list (> 1 entry implies an overlap) */
|
2017-01-30 16:24:39 +08:00
|
|
|
overlap_list[overlap_entries++] = change_point[chg_idx]->entry;
|
2008-05-11 15:30:15 +08:00
|
|
|
} else {
|
2017-01-28 18:13:08 +08:00
|
|
|
/* Remove entry from list (order independent, so swap with last): */
|
2008-05-11 15:30:15 +08:00
|
|
|
for (i = 0; i < overlap_entries; i++) {
|
2017-01-30 16:24:39 +08:00
|
|
|
if (overlap_list[i] == change_point[chg_idx]->entry)
|
2017-01-28 18:13:08 +08:00
|
|
|
overlap_list[i] = overlap_list[overlap_entries-1];
|
2008-05-11 15:30:15 +08:00
|
|
|
}
|
|
|
|
overlap_entries--;
|
|
|
|
}
|
|
|
|
/*
|
2017-01-28 18:13:08 +08:00
|
|
|
* If there are overlapping entries, decide which
|
2008-05-11 15:30:15 +08:00
|
|
|
* "type" to use (larger value takes precedence --
|
|
|
|
* 1=usable, 2,3,4,4+=unusable)
|
|
|
|
*/
|
|
|
|
current_type = 0;
|
2017-01-28 18:13:08 +08:00
|
|
|
for (i = 0; i < overlap_entries; i++) {
|
2008-05-11 15:30:15 +08:00
|
|
|
if (overlap_list[i]->type > current_type)
|
|
|
|
current_type = overlap_list[i]->type;
|
2017-01-28 18:13:08 +08:00
|
|
|
}
|
|
|
|
|
2017-01-29 01:35:24 +08:00
|
|
|
/* Continue building up new map based on this information: */
|
2017-01-29 00:09:33 +08:00
|
|
|
if (current_type != last_type || current_type == E820_TYPE_PRAM) {
|
2008-05-11 15:30:15 +08:00
|
|
|
if (last_type != 0) {
|
2017-01-30 16:24:39 +08:00
|
|
|
new_entries[new_nr_entries].size = change_point[chg_idx]->addr - last_addr;
|
2017-01-28 18:13:08 +08:00
|
|
|
/* Move forward only if the new size was non-zero: */
|
2017-01-29 01:35:24 +08:00
|
|
|
if (new_entries[new_nr_entries].size != 0)
|
|
|
|
/* No more space left for new entries? */
|
|
|
|
if (++new_nr_entries >= max_nr_entries)
|
2008-05-11 15:30:15 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (current_type != 0) {
|
2017-01-30 16:24:39 +08:00
|
|
|
new_entries[new_nr_entries].addr = change_point[chg_idx]->addr;
|
2017-01-29 01:35:24 +08:00
|
|
|
new_entries[new_nr_entries].type = current_type;
|
2017-01-30 16:24:39 +08:00
|
|
|
last_addr = change_point[chg_idx]->addr;
|
2008-05-11 15:30:15 +08:00
|
|
|
}
|
|
|
|
last_type = current_type;
|
|
|
|
}
|
|
|
|
}
|
2017-01-28 18:13:08 +08:00
|
|
|
|
2017-01-29 01:35:24 +08:00
|
|
|
/* Copy the new entries into the original location: */
|
2017-01-30 16:24:39 +08:00
|
|
|
memcpy(entries, new_entries, new_nr_entries*sizeof(*entries));
|
|
|
|
table->nr_entries = new_nr_entries;
|
2008-05-11 15:30:15 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-01-29 19:56:13 +08:00
|
|
|
static int __init __append_e820_table(struct boot_e820_entry *entries, u32 nr_entries)
|
2008-06-11 11:33:39 +08:00
|
|
|
{
|
2017-01-29 19:56:13 +08:00
|
|
|
struct boot_e820_entry *entry = entries;
|
2017-01-29 01:35:24 +08:00
|
|
|
|
|
|
|
while (nr_entries) {
|
|
|
|
u64 start = entry->addr;
|
|
|
|
u64 size = entry->size;
|
2016-08-20 09:40:13 +08:00
|
|
|
u64 end = start + size - 1;
|
2017-01-29 01:35:24 +08:00
|
|
|
u32 type = entry->type;
|
2008-06-11 11:33:39 +08:00
|
|
|
|
2017-01-28 18:13:08 +08:00
|
|
|
/* Ignore the entry on 64-bit overflow: */
|
2016-08-20 09:40:13 +08:00
|
|
|
if (start > end && likely(size))
|
2008-06-11 11:33:39 +08: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 21:19:36 +08:00
|
|
|
e820__range_add(start, size, type);
|
2008-06-11 11:33:39 +08:00
|
|
|
|
2017-01-29 01:35:24 +08:00
|
|
|
entry++;
|
|
|
|
nr_entries--;
|
2008-06-11 11:33:39 +08:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-05-11 15:30:15 +08:00
|
|
|
/*
|
2017-01-28 18:13:08 +08:00
|
|
|
* Copy the BIOS E820 map into a safe place.
|
2008-05-11 15:30:15 +08: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-29 19:56:13 +08:00
|
|
|
static int __init append_e820_table(struct boot_e820_entry *entries, u32 nr_entries)
|
2008-05-11 15:30:15 +08:00
|
|
|
{
|
|
|
|
/* Only one memory region (or negative)? Ignore it */
|
2017-01-29 01:35:24 +08:00
|
|
|
if (nr_entries < 2)
|
2008-05-11 15:30:15 +08:00
|
|
|
return -1;
|
|
|
|
|
2017-01-29 01:35:24 +08:00
|
|
|
return __append_e820_table(entries, nr_entries);
|
2008-05-11 15:30:15 +08:00
|
|
|
}
|
|
|
|
|
2017-01-28 18:13:08 +08:00
|
|
|
static u64 __init
|
2017-01-28 23:52:34 +08:00
|
|
|
__e820__range_update(struct e820_table *table, u64 start, u64 size, enum e820_type old_type, enum e820_type new_type)
|
2008-05-11 15:30:15 +08:00
|
|
|
{
|
2009-03-13 13:36:01 +08:00
|
|
|
u64 end;
|
2009-03-13 12:35:18 +08:00
|
|
|
unsigned int i;
|
2008-05-11 15:30:15 +08:00
|
|
|
u64 real_updated_size = 0;
|
|
|
|
|
|
|
|
BUG_ON(old_type == new_type);
|
|
|
|
|
2008-06-25 05:58:38 +08:00
|
|
|
if (size > (ULLONG_MAX - start))
|
|
|
|
size = ULLONG_MAX - start;
|
|
|
|
|
2009-03-13 13:36:01 +08:00
|
|
|
end = start + size;
|
2017-02-01 01:53:34 +08:00
|
|
|
printk(KERN_DEBUG "e820: update [mem %#010Lx-%#010Lx] ", start, end - 1);
|
2009-03-15 15:59:19 +08:00
|
|
|
e820_print_type(old_type);
|
2017-01-28 19:27:45 +08:00
|
|
|
pr_cont(" ==> ");
|
2009-03-15 15:59:19 +08:00
|
|
|
e820_print_type(new_type);
|
2017-01-28 19:27:45 +08:00
|
|
|
pr_cont("\n");
|
2009-03-15 15:59:19 +08:00
|
|
|
|
2017-01-27 21:06:21 +08:00
|
|
|
for (i = 0; i < table->nr_entries; i++) {
|
2017-01-28 19:16:17 +08:00
|
|
|
struct e820_entry *entry = &table->entries[i];
|
2008-05-11 15:30:15 +08:00
|
|
|
u64 final_start, final_end;
|
2017-01-28 19:16:17 +08:00
|
|
|
u64 entry_end;
|
2009-03-13 13:36:01 +08:00
|
|
|
|
2017-01-28 19:16:17 +08:00
|
|
|
if (entry->type != old_type)
|
2008-05-11 15:30:15 +08:00
|
|
|
continue;
|
2009-03-13 13:36:01 +08:00
|
|
|
|
2017-01-28 19:16:17 +08:00
|
|
|
entry_end = entry->addr + entry->size;
|
2017-01-28 18:13:08 +08:00
|
|
|
|
|
|
|
/* Completely covered by new range? */
|
2017-01-28 19:16:17 +08:00
|
|
|
if (entry->addr >= start && entry_end <= end) {
|
|
|
|
entry->type = new_type;
|
|
|
|
real_updated_size += entry->size;
|
2008-05-11 15:30:15 +08:00
|
|
|
continue;
|
|
|
|
}
|
2009-03-13 13:36:01 +08:00
|
|
|
|
2017-01-28 18:13:08 +08:00
|
|
|
/* New range is completely covered? */
|
2017-01-28 19:16:17 +08: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 21:19:36 +08:00
|
|
|
__e820__range_add(table, start, size, new_type);
|
|
|
|
__e820__range_add(table, end, entry_end - end, entry->type);
|
2017-01-28 19:16:17 +08:00
|
|
|
entry->size = start - entry->addr;
|
2009-03-13 13:36:01 +08:00
|
|
|
real_updated_size += size;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2017-01-28 18:13:08 +08:00
|
|
|
/* Partially covered: */
|
2017-01-28 19:16:17 +08:00
|
|
|
final_start = max(start, entry->addr);
|
|
|
|
final_end = min(end, entry_end);
|
2008-05-11 15:30:15 +08:00
|
|
|
if (final_start >= final_end)
|
|
|
|
continue;
|
2009-03-12 21:07:23 +08: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 21:19:36 +08:00
|
|
|
__e820__range_add(table, final_start, final_end - final_start, new_type);
|
2009-03-12 21:07:23 +08:00
|
|
|
|
2008-05-11 15:30:15 +08:00
|
|
|
real_updated_size += final_end - final_start;
|
2008-06-25 05:55:32 +08:00
|
|
|
|
2009-03-13 12:35:18 +08:00
|
|
|
/*
|
2017-01-28 18:13:08 +08:00
|
|
|
* Left range could be head or tail, so need to update
|
|
|
|
* its size first:
|
2009-03-13 12:35:18 +08:00
|
|
|
*/
|
2017-01-28 19:16:17 +08:00
|
|
|
entry->size -= final_end - final_start;
|
|
|
|
if (entry->addr < final_start)
|
2008-06-25 05:55:32 +08:00
|
|
|
continue;
|
2017-01-28 18:13:08 +08:00
|
|
|
|
2017-01-28 19:16:17 +08:00
|
|
|
entry->addr = final_end;
|
2008-05-11 15:30:15 +08:00
|
|
|
}
|
|
|
|
return real_updated_size;
|
|
|
|
}
|
|
|
|
|
2017-01-28 23:52:34 +08:00
|
|
|
u64 __init e820__range_update(u64 start, u64 size, enum e820_type old_type, enum e820_type new_type)
|
2008-07-04 02:39:00 +08: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 21:19:36 +08:00
|
|
|
return __e820__range_update(e820_table, start, size, old_type, new_type);
|
2008-07-04 02:39:00 +08:00
|
|
|
}
|
|
|
|
|
2017-07-03 01:07:12 +08:00
|
|
|
static u64 __init e820__range_update_kexec(u64 start, u64 size, enum e820_type old_type, enum e820_type new_type)
|
2008-07-04 02:39:00 +08:00
|
|
|
{
|
2017-07-03 01:07:12 +08:00
|
|
|
return __e820__range_update(e820_table_kexec, start, size, old_type, new_type);
|
2008-07-04 02:39:00 +08:00
|
|
|
}
|
|
|
|
|
2017-01-28 18:13:08 +08:00
|
|
|
/* Remove a range of memory from the E820 table: */
|
2017-01-29 05:34:55 +08:00
|
|
|
u64 __init e820__range_remove(u64 start, u64 size, enum e820_type old_type, bool check_type)
|
2008-06-22 05:48:05 +08:00
|
|
|
{
|
|
|
|
int i;
|
2010-01-22 11:21:04 +08:00
|
|
|
u64 end;
|
2008-06-22 05:48:05 +08:00
|
|
|
u64 real_removed_size = 0;
|
|
|
|
|
2008-06-25 05:58:38 +08:00
|
|
|
if (size > (ULLONG_MAX - start))
|
|
|
|
size = ULLONG_MAX - start;
|
|
|
|
|
2010-01-22 11:21:04 +08:00
|
|
|
end = start + size;
|
2017-02-01 01:53:34 +08:00
|
|
|
printk(KERN_DEBUG "e820: remove [mem %#010Lx-%#010Lx] ", start, end - 1);
|
2017-01-29 05:34:55 +08:00
|
|
|
if (check_type)
|
2010-03-30 13:38:29 +08:00
|
|
|
e820_print_type(old_type);
|
2017-01-28 19:27:45 +08:00
|
|
|
pr_cont("\n");
|
2010-01-22 11:21:04 +08:00
|
|
|
|
2017-01-27 21:06:21 +08:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
2017-01-28 19:16:17 +08:00
|
|
|
struct e820_entry *entry = &e820_table->entries[i];
|
2008-06-22 05:48:05 +08:00
|
|
|
u64 final_start, final_end;
|
2017-01-28 19:16:17 +08:00
|
|
|
u64 entry_end;
|
2008-06-22 05:48:05 +08:00
|
|
|
|
2017-01-29 05:34:55 +08:00
|
|
|
if (check_type && entry->type != old_type)
|
2008-06-22 05:48:05 +08:00
|
|
|
continue;
|
2010-03-30 13:38:29 +08:00
|
|
|
|
2017-01-28 19:16:17 +08:00
|
|
|
entry_end = entry->addr + entry->size;
|
2017-01-28 18:13:08 +08:00
|
|
|
|
|
|
|
/* Completely covered? */
|
2017-01-28 19:16:17 +08:00
|
|
|
if (entry->addr >= start && entry_end <= end) {
|
|
|
|
real_removed_size += entry->size;
|
2017-01-29 00:48:08 +08:00
|
|
|
memset(entry, 0, sizeof(*entry));
|
2008-06-22 05:48:05 +08:00
|
|
|
continue;
|
|
|
|
}
|
2010-03-30 13:38:29 +08:00
|
|
|
|
2017-01-28 18:13:08 +08:00
|
|
|
/* Is the new range completely covered? */
|
2017-01-28 19:16:17 +08: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 21:19:36 +08:00
|
|
|
e820__range_add(end, entry_end - end, entry->type);
|
2017-01-28 19:16:17 +08:00
|
|
|
entry->size = start - entry->addr;
|
2010-03-30 13:38:29 +08:00
|
|
|
real_removed_size += size;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2017-01-28 18:13:08 +08:00
|
|
|
/* Partially covered: */
|
2017-01-28 19:16:17 +08:00
|
|
|
final_start = max(start, entry->addr);
|
|
|
|
final_end = min(end, entry_end);
|
2008-06-22 05:48:05 +08:00
|
|
|
if (final_start >= final_end)
|
|
|
|
continue;
|
2017-01-28 18:13:08 +08:00
|
|
|
|
2008-06-22 05:48:05 +08:00
|
|
|
real_removed_size += final_end - final_start;
|
|
|
|
|
2010-03-30 13:38:29 +08:00
|
|
|
/*
|
2017-01-28 18:13:08 +08:00
|
|
|
* Left range could be head or tail, so need to update
|
|
|
|
* the size first:
|
2010-03-30 13:38:29 +08:00
|
|
|
*/
|
2017-01-28 19:16:17 +08:00
|
|
|
entry->size -= final_end - final_start;
|
|
|
|
if (entry->addr < final_start)
|
2008-06-22 05:48:05 +08:00
|
|
|
continue;
|
2017-01-28 18:13:08 +08:00
|
|
|
|
2017-01-28 19:16:17 +08:00
|
|
|
entry->addr = final_end;
|
2008-06-22 05:48:05 +08:00
|
|
|
}
|
|
|
|
return real_removed_size;
|
|
|
|
}
|
|
|
|
|
2017-01-28 21:03:04 +08:00
|
|
|
void __init e820__update_table_print(void)
|
2008-05-11 15:30:15 +08:00
|
|
|
{
|
x86/boot/e820: Simplify the e820__update_table() interface
The e820__update_table() parameters are pretty complex:
arch/x86/include/asm/e820/api.h:extern int e820__update_table(struct e820_entry *biosmap, int max_nr_map, u32 *pnr_map);
But 90% of the usage is trivial:
arch/x86/kernel/e820.c: if (e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries))
arch/x86/kernel/e820.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/kernel/e820.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/kernel/e820.c: if (e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries) < 0)
arch/x86/kernel/e820.c: e820__update_table(boot_params.e820_table, ARRAY_SIZE(boot_params.e820_table), &new_nr);
arch/x86/kernel/early-quirks.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/kernel/setup.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/kernel/setup.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/platform/efi/efi.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/xen/setup.c: e820__update_table(xen_e820_table.entries, ARRAY_SIZE(xen_e820_table.entries),
arch/x86/xen/setup.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/xen/setup.c: e820__update_table(xen_e820_table.entries, ARRAY_SIZE(xen_e820_table.entries),
as it only uses an exiting struct e820_table's entries array, its size and
its current number of entries as input and output arguments.
Only one use is non-trivial:
arch/x86/kernel/e820.c: e820__update_table(boot_params.e820_table, ARRAY_SIZE(boot_params.e820_table), &new_nr);
... which call updates the E820 table in the zeropage in-situ, and the layout there does not
match that of 'struct e820_table' (in particular nr_entries is at a different offset,
hardcoded by the boot protocol).
Simplify all this by introducing a low level __e820__update_table() API that
the zeropage update call can use, and simplifying the main e820__update_table()
call signature down to:
int e820__update_table(struct e820_table *table);
This visibly simplifies all the call sites:
arch/x86/include/asm/e820/api.h:extern int e820__update_table(struct e820_table *table);
arch/x86/include/asm/e820/types.h: * call to e820__update_table() to remove duplicates. The allowance
arch/x86/kernel/e820.c: * The return value from e820__update_table() is zero if it
arch/x86/kernel/e820.c:int __init e820__update_table(struct e820_table *table)
arch/x86/kernel/e820.c: if (e820__update_table(e820_table))
arch/x86/kernel/e820.c: e820__update_table(e820_table_firmware);
arch/x86/kernel/e820.c: e820__update_table(e820_table);
arch/x86/kernel/e820.c: e820__update_table(e820_table);
arch/x86/kernel/e820.c: if (e820__update_table(e820_table) < 0)
arch/x86/kernel/early-quirks.c: e820__update_table(e820_table);
arch/x86/kernel/setup.c: e820__update_table(e820_table);
arch/x86/kernel/setup.c: e820__update_table(e820_table);
arch/x86/platform/efi/efi.c: e820__update_table(e820_table);
arch/x86/xen/setup.c: e820__update_table(&xen_e820_table);
arch/x86/xen/setup.c: e820__update_table(e820_table);
arch/x86/xen/setup.c: e820__update_table(&xen_e820_table);
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-29 01:00:35 +08:00
|
|
|
if (e820__update_table(e820_table))
|
2008-05-11 15:30:15 +08:00
|
|
|
return;
|
2017-01-28 18:13:08 +08:00
|
|
|
|
2018-05-10 23:45:30 +08:00
|
|
|
pr_info("modified physical RAM map:\n");
|
2017-01-28 21:24:02 +08:00
|
|
|
e820__print_table("modified");
|
2008-05-11 15:30:15 +08:00
|
|
|
}
|
2017-01-28 18:13:08 +08:00
|
|
|
|
2017-07-03 01:07:12 +08:00
|
|
|
static void __init e820__update_table_kexec(void)
|
2008-07-04 02:39:00 +08:00
|
|
|
{
|
2017-07-03 01:07:12 +08:00
|
|
|
e820__update_table(e820_table_kexec);
|
2008-07-04 02:39:00 +08:00
|
|
|
}
|
2017-01-28 18:13:08 +08:00
|
|
|
|
2008-06-26 02:02:42 +08:00
|
|
|
#define MAX_GAP_END 0x100000000ull
|
2017-01-28 18:13:08 +08:00
|
|
|
|
2008-05-11 15:30:15 +08:00
|
|
|
/*
|
2017-01-28 18:13:08 +08:00
|
|
|
* Search for a gap in the E820 memory space from 0 to MAX_GAP_END (4GB).
|
2008-05-11 15:30:15 +08:00
|
|
|
*/
|
2017-01-28 18:13:08 +08:00
|
|
|
static int __init e820_search_gap(unsigned long *gapstart, unsigned long *gapsize)
|
2008-05-11 15:30:15 +08:00
|
|
|
{
|
2016-12-25 22:35:51 +08:00
|
|
|
unsigned long long last = MAX_GAP_END;
|
2017-01-27 21:06:21 +08:00
|
|
|
int i = e820_table->nr_entries;
|
2008-05-11 15:30:15 +08:00
|
|
|
int found = 0;
|
|
|
|
|
|
|
|
while (--i >= 0) {
|
2017-01-27 21:06:21 +08:00
|
|
|
unsigned long long start = e820_table->entries[i].addr;
|
|
|
|
unsigned long long end = start + e820_table->entries[i].size;
|
2008-05-11 15:30:15 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Since "last" is at most 4GB, we know we'll
|
2017-01-28 18:13:08 +08:00
|
|
|
* fit in 32 bits if this condition is true:
|
2008-05-11 15:30:15 +08:00
|
|
|
*/
|
|
|
|
if (last > end) {
|
|
|
|
unsigned long gap = last - end;
|
|
|
|
|
2008-06-25 02:48:30 +08:00
|
|
|
if (gap >= *gapsize) {
|
|
|
|
*gapsize = gap;
|
|
|
|
*gapstart = end;
|
2008-05-11 15:30:15 +08:00
|
|
|
found = 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (start < last)
|
|
|
|
last = start;
|
|
|
|
}
|
2008-06-25 02:48:30 +08:00
|
|
|
return found;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2017-01-28 18:13:08 +08: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-25 02:48:30 +08:00
|
|
|
* Hopefully the BIOS let enough space left.
|
|
|
|
*/
|
2017-01-28 21:16:38 +08:00
|
|
|
__init void e820__setup_pci_gap(void)
|
2008-06-25 02:48:30 +08:00
|
|
|
{
|
2009-05-06 23:07:52 +08:00
|
|
|
unsigned long gapstart, gapsize;
|
2008-06-25 02:48:30 +08:00
|
|
|
int found;
|
|
|
|
|
|
|
|
gapsize = 0x400000;
|
2016-12-25 22:35:51 +08:00
|
|
|
found = e820_search_gap(&gapstart, &gapsize);
|
2008-05-11 15:30:15 +08:00
|
|
|
|
|
|
|
if (!found) {
|
2017-01-11 22:49:04 +08:00
|
|
|
#ifdef CONFIG_X86_64
|
2008-06-25 13:14:09 +08:00
|
|
|
gapstart = (max_pfn << PAGE_SHIFT) + 1024*1024;
|
2018-05-10 23:45:30 +08:00
|
|
|
pr_err("Cannot find an available gap in the 32-bit address range\n");
|
|
|
|
pr_err("PCI devices with unassigned 32-bit BARs may not work!\n");
|
2017-01-11 22:49:04 +08:00
|
|
|
#else
|
|
|
|
gapstart = 0x10000000;
|
2008-05-11 15:30:15 +08:00
|
|
|
#endif
|
2017-01-11 22:49:04 +08:00
|
|
|
}
|
2008-05-11 15:30:15 +08:00
|
|
|
|
|
|
|
/*
|
2017-01-29 05:41:14 +08:00
|
|
|
* e820__reserve_resources_late() protects stolen RAM already:
|
2008-05-11 15:30:15 +08:00
|
|
|
*/
|
2009-05-06 23:07:52 +08:00
|
|
|
pci_mem_start = gapstart;
|
2008-05-11 15:30:15 +08:00
|
|
|
|
2018-05-10 23:45:30 +08:00
|
|
|
pr_info("[mem %#010lx-%#010lx] available for PCI devices\n",
|
|
|
|
gapstart, gapstart + gapsize - 1);
|
2008-05-11 15:30:15 +08:00
|
|
|
}
|
|
|
|
|
2016-09-18 05:39:26 +08:00
|
|
|
/*
|
|
|
|
* Called late during init, in free_initmem().
|
|
|
|
*
|
2017-07-03 01:07:12 +08:00
|
|
|
* Initial e820_table and e820_table_kexec are largish __initdata arrays.
|
2017-01-28 18:13:08 +08:00
|
|
|
*
|
|
|
|
* 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-18 05:39:26 +08:00
|
|
|
*/
|
2017-01-29 05:52:16 +08:00
|
|
|
__init void e820__reallocate_tables(void)
|
2016-09-18 05:39:26 +08:00
|
|
|
{
|
2017-01-27 20:54:38 +08:00
|
|
|
struct e820_table *n;
|
2016-09-18 05:39:26 +08:00
|
|
|
int size;
|
|
|
|
|
2017-01-28 18:13:08 +08:00
|
|
|
size = offsetof(struct e820_table, entries) + sizeof(struct e820_entry)*e820_table->nr_entries;
|
2016-09-18 05:39:26 +08:00
|
|
|
n = kmalloc(size, GFP_KERNEL);
|
|
|
|
BUG_ON(!n);
|
2017-01-27 20:54:38 +08:00
|
|
|
memcpy(n, e820_table, size);
|
|
|
|
e820_table = n;
|
2016-09-18 05:39:26 +08:00
|
|
|
|
2017-07-03 01:07:12 +08:00
|
|
|
size = offsetof(struct e820_table, entries) + sizeof(struct e820_entry)*e820_table_kexec->nr_entries;
|
2016-09-18 05:39:26 +08:00
|
|
|
n = kmalloc(size, GFP_KERNEL);
|
|
|
|
BUG_ON(!n);
|
2017-07-03 01:07:12 +08:00
|
|
|
memcpy(n, e820_table_kexec, size);
|
|
|
|
e820_table_kexec = n;
|
2017-07-03 01:07:32 +08:00
|
|
|
|
|
|
|
size = offsetof(struct e820_table, entries) + sizeof(struct e820_entry)*e820_table_firmware->nr_entries;
|
|
|
|
n = kmalloc(size, GFP_KERNEL);
|
|
|
|
BUG_ON(!n);
|
|
|
|
memcpy(n, e820_table_firmware, size);
|
|
|
|
e820_table_firmware = n;
|
2016-09-18 05:39:26 +08:00
|
|
|
}
|
|
|
|
|
2017-01-28 18:13:08 +08: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 11:33:39 +08:00
|
|
|
*/
|
2017-01-28 20:18:40 +08:00
|
|
|
void __init e820__memory_setup_extended(u64 phys_addr, u32 data_len)
|
2008-06-11 11:33:39 +08:00
|
|
|
{
|
|
|
|
int entries;
|
2017-01-29 19:56:13 +08:00
|
|
|
struct boot_e820_entry *extmap;
|
2013-08-14 05:46:41 +08:00
|
|
|
struct setup_data *sdata;
|
2008-06-11 11:33:39 +08:00
|
|
|
|
2013-08-14 05:46:41 +08:00
|
|
|
sdata = early_memremap(phys_addr, data_len);
|
2017-01-29 00:48:08 +08:00
|
|
|
entries = sdata->len / sizeof(*extmap);
|
2017-01-29 19:56:13 +08:00
|
|
|
extmap = (struct boot_e820_entry *)(sdata->data);
|
2017-01-28 18:13:08 +08:00
|
|
|
|
2017-01-27 20:54:38 +08:00
|
|
|
__append_e820_table(extmap, entries);
|
x86/boot/e820: Simplify the e820__update_table() interface
The e820__update_table() parameters are pretty complex:
arch/x86/include/asm/e820/api.h:extern int e820__update_table(struct e820_entry *biosmap, int max_nr_map, u32 *pnr_map);
But 90% of the usage is trivial:
arch/x86/kernel/e820.c: if (e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries))
arch/x86/kernel/e820.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/kernel/e820.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/kernel/e820.c: if (e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries) < 0)
arch/x86/kernel/e820.c: e820__update_table(boot_params.e820_table, ARRAY_SIZE(boot_params.e820_table), &new_nr);
arch/x86/kernel/early-quirks.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/kernel/setup.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/kernel/setup.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/platform/efi/efi.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/xen/setup.c: e820__update_table(xen_e820_table.entries, ARRAY_SIZE(xen_e820_table.entries),
arch/x86/xen/setup.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/xen/setup.c: e820__update_table(xen_e820_table.entries, ARRAY_SIZE(xen_e820_table.entries),
as it only uses an exiting struct e820_table's entries array, its size and
its current number of entries as input and output arguments.
Only one use is non-trivial:
arch/x86/kernel/e820.c: e820__update_table(boot_params.e820_table, ARRAY_SIZE(boot_params.e820_table), &new_nr);
... which call updates the E820 table in the zeropage in-situ, and the layout there does not
match that of 'struct e820_table' (in particular nr_entries is at a different offset,
hardcoded by the boot protocol).
Simplify all this by introducing a low level __e820__update_table() API that
the zeropage update call can use, and simplifying the main e820__update_table()
call signature down to:
int e820__update_table(struct e820_table *table);
This visibly simplifies all the call sites:
arch/x86/include/asm/e820/api.h:extern int e820__update_table(struct e820_table *table);
arch/x86/include/asm/e820/types.h: * call to e820__update_table() to remove duplicates. The allowance
arch/x86/kernel/e820.c: * The return value from e820__update_table() is zero if it
arch/x86/kernel/e820.c:int __init e820__update_table(struct e820_table *table)
arch/x86/kernel/e820.c: if (e820__update_table(e820_table))
arch/x86/kernel/e820.c: e820__update_table(e820_table_firmware);
arch/x86/kernel/e820.c: e820__update_table(e820_table);
arch/x86/kernel/e820.c: e820__update_table(e820_table);
arch/x86/kernel/e820.c: if (e820__update_table(e820_table) < 0)
arch/x86/kernel/early-quirks.c: e820__update_table(e820_table);
arch/x86/kernel/setup.c: e820__update_table(e820_table);
arch/x86/kernel/setup.c: e820__update_table(e820_table);
arch/x86/platform/efi/efi.c: e820__update_table(e820_table);
arch/x86/xen/setup.c: e820__update_table(&xen_e820_table);
arch/x86/xen/setup.c: e820__update_table(e820_table);
arch/x86/xen/setup.c: e820__update_table(&xen_e820_table);
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-29 01:00:35 +08:00
|
|
|
e820__update_table(e820_table);
|
2017-01-28 18:13:08 +08:00
|
|
|
|
2017-07-03 01:07:12 +08:00
|
|
|
memcpy(e820_table_kexec, e820_table, sizeof(*e820_table_kexec));
|
2017-07-03 01:07:32 +08:00
|
|
|
memcpy(e820_table_firmware, e820_table, sizeof(*e820_table_firmware));
|
2017-07-03 01:06:28 +08:00
|
|
|
|
2015-02-24 17:13:28 +08:00
|
|
|
early_memunmap(sdata, data_len);
|
2018-05-10 23:45:30 +08:00
|
|
|
pr_info("extended physical RAM map:\n");
|
2017-01-28 21:24:02 +08:00
|
|
|
e820__print_table("extended");
|
2008-06-11 11:33:39 +08:00
|
|
|
}
|
|
|
|
|
2017-01-29 05:44:12 +08:00
|
|
|
/*
|
2008-05-21 11:10:58 +08:00
|
|
|
* Find the ranges of physical addresses that do not correspond to
|
2017-01-29 05:44:12 +08:00
|
|
|
* E820 RAM areas and register the corresponding pages as 'nosave' for
|
2017-01-28 18:13:08 +08:00
|
|
|
* hibernation (32-bit) or software suspend and suspend to RAM (64-bit).
|
2008-05-21 11:10:58 +08:00
|
|
|
*
|
2017-01-28 18:13:08 +08:00
|
|
|
* This function requires the E820 map to be sorted and without any
|
2014-09-12 11:03:58 +08:00
|
|
|
* overlapping entries.
|
2008-05-21 11:10:58 +08:00
|
|
|
*/
|
2017-01-29 05:44:12 +08:00
|
|
|
void __init e820__register_nosave_regions(unsigned long limit_pfn)
|
2008-05-21 11:10:58 +08:00
|
|
|
{
|
|
|
|
int i;
|
2014-09-12 11:03:58 +08:00
|
|
|
unsigned long pfn = 0;
|
2008-05-21 11:10:58 +08:00
|
|
|
|
2017-01-27 21:06:21 +08:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
2017-01-28 19:16:17 +08:00
|
|
|
struct e820_entry *entry = &e820_table->entries[i];
|
2008-05-21 11:10:58 +08:00
|
|
|
|
2017-01-28 19:16:17 +08:00
|
|
|
if (pfn < PFN_UP(entry->addr))
|
|
|
|
register_nosave_region(pfn, PFN_UP(entry->addr));
|
2008-05-21 11:10:58 +08:00
|
|
|
|
2017-01-28 19:16:17 +08:00
|
|
|
pfn = PFN_DOWN(entry->addr + entry->size);
|
2015-04-01 15:12:18 +08:00
|
|
|
|
2017-01-29 00:09:33 +08:00
|
|
|
if (entry->type != E820_TYPE_RAM && entry->type != E820_TYPE_RESERVED_KERN)
|
2017-01-28 19:16:17 +08:00
|
|
|
register_nosave_region(PFN_UP(entry->addr), pfn);
|
2008-05-21 11:10:58 +08:00
|
|
|
|
|
|
|
if (pfn >= limit_pfn)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2008-05-18 16:18:57 +08:00
|
|
|
|
2011-12-08 11:25:49 +08:00
|
|
|
#ifdef CONFIG_ACPI
|
2017-01-28 18:13:08 +08:00
|
|
|
/*
|
|
|
|
* Register ACPI NVS memory regions, so that we can save/restore them during
|
|
|
|
* hibernation and the subsequent resume:
|
2008-10-31 08:02:41 +08:00
|
|
|
*/
|
2017-01-29 05:44:12 +08:00
|
|
|
static int __init e820__register_nvs_regions(void)
|
2008-10-31 08:02:41 +08:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2017-01-27 21:06:21 +08:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
2017-01-28 19:16:17 +08:00
|
|
|
struct e820_entry *entry = &e820_table->entries[i];
|
2008-10-31 08:02:41 +08:00
|
|
|
|
2017-01-29 00:09:33 +08:00
|
|
|
if (entry->type == E820_TYPE_NVS)
|
2017-01-28 19:16:17 +08:00
|
|
|
acpi_nvs_register(entry->addr, entry->size);
|
2008-10-31 08:02:41 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2017-01-29 05:44:12 +08:00
|
|
|
core_initcall(e820__register_nvs_regions);
|
2008-10-31 08:02:41 +08:00
|
|
|
#endif
|
|
|
|
|
2008-06-02 04:17:38 +08:00
|
|
|
/*
|
2017-01-28 20:46:28 +08:00
|
|
|
* Allocate the requested number of bytes with the requsted alignment
|
|
|
|
* and return (the physical address) to the caller. Also register this
|
2017-07-03 01:07:12 +08:00
|
|
|
* range in the 'kexec' E820 table as a reserved range.
|
2017-01-28 20:46:28 +08:00
|
|
|
*
|
|
|
|
* This allows kexec to fake a new mptable, as if it came from the real
|
|
|
|
* system.
|
2008-06-02 04:17:38 +08:00
|
|
|
*/
|
2017-01-28 20:46:28 +08:00
|
|
|
u64 __init e820__memblock_alloc_reserved(u64 size, u64 align)
|
2008-06-02 04:17:38 +08:00
|
|
|
{
|
|
|
|
u64 addr;
|
|
|
|
|
2011-07-12 17:15:58 +08:00
|
|
|
addr = __memblock_alloc_base(size, align, MEMBLOCK_ALLOC_ACCESSIBLE);
|
|
|
|
if (addr) {
|
2017-07-03 01:07:12 +08:00
|
|
|
e820__range_update_kexec(addr, size, E820_TYPE_RAM, E820_TYPE_RESERVED);
|
2018-05-10 23:45:30 +08:00
|
|
|
pr_info("update e820_table_kexec for e820__memblock_alloc_reserved()\n");
|
2017-07-03 01:07:12 +08:00
|
|
|
e820__update_table_kexec();
|
2009-05-06 20:02:19 +08:00
|
|
|
}
|
2008-06-02 04:17:38 +08:00
|
|
|
|
|
|
|
return addr;
|
|
|
|
}
|
|
|
|
|
2008-06-04 10:34:00 +08: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-05 04:21:29 +08:00
|
|
|
# define MAX_ARCH_PFN MAXMEM>>PAGE_SHIFT
|
2008-06-04 10:34:00 +08:00
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Find the highest page frame number we have available
|
|
|
|
*/
|
2017-01-28 23:52:34 +08:00
|
|
|
static unsigned long __init e820_end_pfn(unsigned long limit_pfn, enum e820_type type)
|
2008-06-04 10:34:00 +08:00
|
|
|
{
|
2008-07-09 09:56:38 +08:00
|
|
|
int i;
|
|
|
|
unsigned long last_pfn = 0;
|
2008-06-04 10:34:00 +08:00
|
|
|
unsigned long max_arch_pfn = MAX_ARCH_PFN;
|
|
|
|
|
2017-01-27 21:06:21 +08:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
2017-01-28 19:16:17 +08:00
|
|
|
struct e820_entry *entry = &e820_table->entries[i];
|
2008-07-11 11:38:26 +08:00
|
|
|
unsigned long start_pfn;
|
2008-07-09 09:56:38 +08:00
|
|
|
unsigned long end_pfn;
|
|
|
|
|
2017-01-28 19:16:17 +08:00
|
|
|
if (entry->type != type)
|
2008-07-09 18:01:14 +08:00
|
|
|
continue;
|
|
|
|
|
2017-01-28 19:16:17 +08:00
|
|
|
start_pfn = entry->addr >> PAGE_SHIFT;
|
|
|
|
end_pfn = (entry->addr + entry->size) >> PAGE_SHIFT;
|
2008-07-11 11:38:26 +08:00
|
|
|
|
|
|
|
if (start_pfn >= limit_pfn)
|
|
|
|
continue;
|
|
|
|
if (end_pfn > limit_pfn) {
|
|
|
|
last_pfn = limit_pfn;
|
|
|
|
break;
|
|
|
|
}
|
2008-07-09 09:56:38 +08:00
|
|
|
if (end_pfn > last_pfn)
|
|
|
|
last_pfn = end_pfn;
|
|
|
|
}
|
2008-06-04 10:34:00 +08:00
|
|
|
|
|
|
|
if (last_pfn > max_arch_pfn)
|
|
|
|
last_pfn = max_arch_pfn;
|
|
|
|
|
2018-05-10 23:45:30 +08:00
|
|
|
pr_info("last_pfn = %#lx max_arch_pfn = %#lx\n",
|
|
|
|
last_pfn, max_arch_pfn);
|
2008-06-04 10:34:00 +08:00
|
|
|
return last_pfn;
|
|
|
|
}
|
2017-01-28 18:13:08 +08:00
|
|
|
|
2017-01-29 05:52:16 +08:00
|
|
|
unsigned long __init e820__end_of_ram_pfn(void)
|
2008-07-11 11:38:26 +08:00
|
|
|
{
|
2017-01-29 00:09:33 +08:00
|
|
|
return e820_end_pfn(MAX_ARCH_PFN, E820_TYPE_RAM);
|
2008-07-11 11:38:26 +08:00
|
|
|
}
|
2008-06-04 10:34:00 +08:00
|
|
|
|
2017-01-29 05:52:16 +08:00
|
|
|
unsigned long __init e820__end_of_low_ram_pfn(void)
|
2008-07-11 11:38:26 +08:00
|
|
|
{
|
2017-01-29 00:09:33 +08:00
|
|
|
return e820_end_pfn(1UL << (32 - PAGE_SHIFT), E820_TYPE_RAM);
|
2008-07-11 11:38:26 +08:00
|
|
|
}
|
2008-06-04 10:34:00 +08:00
|
|
|
|
2016-09-18 05:39:25 +08:00
|
|
|
static void __init early_panic(char *msg)
|
2008-06-11 03:55:54 +08:00
|
|
|
{
|
|
|
|
early_printk(msg);
|
|
|
|
panic(msg);
|
|
|
|
}
|
|
|
|
|
2008-07-10 19:17:00 +08:00
|
|
|
static int userdef __initdata;
|
|
|
|
|
2017-01-28 18:13:08 +08:00
|
|
|
/* The "mem=nopentium" boot option disables 4MB page tables on 32-bit kernels: */
|
2008-06-11 03:55:54 +08:00
|
|
|
static int __init parse_memopt(char *p)
|
|
|
|
{
|
|
|
|
u64 mem_size;
|
|
|
|
|
|
|
|
if (!p)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (!strcmp(p, "nopentium")) {
|
2011-02-04 09:38:05 +08:00
|
|
|
#ifdef CONFIG_X86_32
|
2008-06-11 03:55:54 +08:00
|
|
|
setup_clear_cpu_cap(X86_FEATURE_PSE);
|
|
|
|
return 0;
|
2011-02-04 09:38:05 +08:00
|
|
|
#else
|
2017-01-28 19:27:45 +08:00
|
|
|
pr_warn("mem=nopentium ignored! (only supported on x86_32)\n");
|
2011-02-04 09:38:05 +08:00
|
|
|
return -EINVAL;
|
2008-06-11 03:55:54 +08:00
|
|
|
#endif
|
2011-02-04 09:38:05 +08:00
|
|
|
}
|
2008-06-11 03:55:54 +08:00
|
|
|
|
2008-07-10 19:17:00 +08:00
|
|
|
userdef = 1;
|
2008-06-11 03:55:54 +08:00
|
|
|
mem_size = memparse(p, &p);
|
2017-01-28 18:13:08 +08:00
|
|
|
|
|
|
|
/* Don't remove all memory when getting "mem={invalid}" parameter: */
|
2011-02-04 09:38:04 +08:00
|
|
|
if (mem_size == 0)
|
|
|
|
return -EINVAL;
|
2017-01-28 18:13:08 +08:00
|
|
|
|
2017-01-29 00:09:33 +08:00
|
|
|
e820__range_remove(mem_size, ULLONG_MAX - mem_size, E820_TYPE_RAM, 1);
|
2008-06-26 03:39:16 +08:00
|
|
|
|
2008-06-11 03:55:54 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
early_param("mem", parse_memopt);
|
|
|
|
|
2012-11-17 11:39:23 +08:00
|
|
|
static int __init parse_memmap_one(char *p)
|
2008-06-11 03:55:54 +08:00
|
|
|
{
|
|
|
|
char *oldp;
|
|
|
|
u64 start_at, mem_size;
|
|
|
|
|
2008-07-05 19:53:39 +08:00
|
|
|
if (!p)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2008-09-09 21:56:08 +08:00
|
|
|
if (!strncmp(p, "exactmap", 8)) {
|
2008-06-11 03:55:54 +08:00
|
|
|
#ifdef CONFIG_CRASH_DUMP
|
|
|
|
/*
|
|
|
|
* If we are doing a crash dump, we still need to know
|
2017-01-28 18:13:08 +08:00
|
|
|
* the real memory size before the original memory map is
|
2008-06-11 03:55:54 +08:00
|
|
|
* reset.
|
|
|
|
*/
|
2017-01-29 05:52:16 +08:00
|
|
|
saved_max_pfn = e820__end_of_ram_pfn();
|
2008-06-11 03:55:54 +08:00
|
|
|
#endif
|
2017-01-27 21:06:21 +08:00
|
|
|
e820_table->nr_entries = 0;
|
2008-06-11 03:55:54 +08: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);
|
2017-01-29 00:09:33 +08:00
|
|
|
e820__range_add(start_at, mem_size, E820_TYPE_RAM);
|
2008-06-11 03:55:54 +08:00
|
|
|
} else if (*p == '#') {
|
|
|
|
start_at = memparse(p+1, &p);
|
2017-01-29 00:09:33 +08:00
|
|
|
e820__range_add(start_at, mem_size, E820_TYPE_ACPI);
|
2008-06-11 03:55:54 +08:00
|
|
|
} else if (*p == '$') {
|
|
|
|
start_at = memparse(p+1, &p);
|
2017-01-29 00:09:33 +08:00
|
|
|
e820__range_add(start_at, mem_size, E820_TYPE_RESERVED);
|
2015-04-01 15:12:18 +08:00
|
|
|
} else if (*p == '!') {
|
|
|
|
start_at = memparse(p+1, &p);
|
2017-01-29 00:09:33 +08:00
|
|
|
e820__range_add(start_at, mem_size, E820_TYPE_PRAM);
|
2018-02-03 07:10:20 +08:00
|
|
|
} else if (*p == '%') {
|
|
|
|
enum e820_type from = 0, to = 0;
|
|
|
|
|
|
|
|
start_at = memparse(p + 1, &p);
|
|
|
|
if (*p == '-')
|
|
|
|
from = simple_strtoull(p + 1, &p, 0);
|
|
|
|
if (*p == '+')
|
|
|
|
to = simple_strtoull(p + 1, &p, 0);
|
|
|
|
if (*p != '\0')
|
|
|
|
return -EINVAL;
|
|
|
|
if (from && to)
|
|
|
|
e820__range_update(start_at, mem_size, from, to);
|
|
|
|
else if (to)
|
|
|
|
e820__range_add(start_at, mem_size, to);
|
|
|
|
else if (from)
|
|
|
|
e820__range_remove(start_at, mem_size, from, 1);
|
|
|
|
else
|
|
|
|
e820__range_remove(start_at, mem_size, 0, 0);
|
2017-01-28 18:13:08 +08:00
|
|
|
} else {
|
2017-01-29 00:09:33 +08:00
|
|
|
e820__range_remove(mem_size, ULLONG_MAX - mem_size, E820_TYPE_RAM, 1);
|
2017-01-28 18:13:08 +08:00
|
|
|
}
|
2008-07-13 13:57:07 +08:00
|
|
|
|
2008-06-11 03:55:54 +08:00
|
|
|
return *p == '\0' ? 0 : -EINVAL;
|
|
|
|
}
|
2017-01-28 18:13:08 +08:00
|
|
|
|
2012-11-17 11:39:23 +08: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-11 03:55:54 +08:00
|
|
|
early_param("memmap", parse_memmap_opt);
|
|
|
|
|
2017-01-29 05:27:28 +08:00
|
|
|
/*
|
|
|
|
* Reserve all entries from the bootloader's extensible data nodes list,
|
|
|
|
* because if present we are going to use it later on to fetch e820
|
|
|
|
* entries from it:
|
|
|
|
*/
|
|
|
|
void __init e820__reserve_setup_data(void)
|
2017-01-28 20:25:45 +08:00
|
|
|
{
|
|
|
|
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));
|
2017-01-29 00:09:33 +08:00
|
|
|
e820__range_update(pa_data, sizeof(*data)+data->len, E820_TYPE_RAM, E820_TYPE_RESERVED_KERN);
|
2017-07-03 01:07:12 +08:00
|
|
|
e820__range_update_kexec(pa_data, sizeof(*data)+data->len, E820_TYPE_RAM, E820_TYPE_RESERVED_KERN);
|
2017-01-28 20:25:45 +08:00
|
|
|
pa_data = data->next;
|
|
|
|
early_memunmap(data, sizeof(*data));
|
|
|
|
}
|
|
|
|
|
x86/boot/e820: Simplify the e820__update_table() interface
The e820__update_table() parameters are pretty complex:
arch/x86/include/asm/e820/api.h:extern int e820__update_table(struct e820_entry *biosmap, int max_nr_map, u32 *pnr_map);
But 90% of the usage is trivial:
arch/x86/kernel/e820.c: if (e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries))
arch/x86/kernel/e820.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/kernel/e820.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/kernel/e820.c: if (e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries) < 0)
arch/x86/kernel/e820.c: e820__update_table(boot_params.e820_table, ARRAY_SIZE(boot_params.e820_table), &new_nr);
arch/x86/kernel/early-quirks.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/kernel/setup.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/kernel/setup.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/platform/efi/efi.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/xen/setup.c: e820__update_table(xen_e820_table.entries, ARRAY_SIZE(xen_e820_table.entries),
arch/x86/xen/setup.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/xen/setup.c: e820__update_table(xen_e820_table.entries, ARRAY_SIZE(xen_e820_table.entries),
as it only uses an exiting struct e820_table's entries array, its size and
its current number of entries as input and output arguments.
Only one use is non-trivial:
arch/x86/kernel/e820.c: e820__update_table(boot_params.e820_table, ARRAY_SIZE(boot_params.e820_table), &new_nr);
... which call updates the E820 table in the zeropage in-situ, and the layout there does not
match that of 'struct e820_table' (in particular nr_entries is at a different offset,
hardcoded by the boot protocol).
Simplify all this by introducing a low level __e820__update_table() API that
the zeropage update call can use, and simplifying the main e820__update_table()
call signature down to:
int e820__update_table(struct e820_table *table);
This visibly simplifies all the call sites:
arch/x86/include/asm/e820/api.h:extern int e820__update_table(struct e820_table *table);
arch/x86/include/asm/e820/types.h: * call to e820__update_table() to remove duplicates. The allowance
arch/x86/kernel/e820.c: * The return value from e820__update_table() is zero if it
arch/x86/kernel/e820.c:int __init e820__update_table(struct e820_table *table)
arch/x86/kernel/e820.c: if (e820__update_table(e820_table))
arch/x86/kernel/e820.c: e820__update_table(e820_table_firmware);
arch/x86/kernel/e820.c: e820__update_table(e820_table);
arch/x86/kernel/e820.c: e820__update_table(e820_table);
arch/x86/kernel/e820.c: if (e820__update_table(e820_table) < 0)
arch/x86/kernel/early-quirks.c: e820__update_table(e820_table);
arch/x86/kernel/setup.c: e820__update_table(e820_table);
arch/x86/kernel/setup.c: e820__update_table(e820_table);
arch/x86/platform/efi/efi.c: e820__update_table(e820_table);
arch/x86/xen/setup.c: e820__update_table(&xen_e820_table);
arch/x86/xen/setup.c: e820__update_table(e820_table);
arch/x86/xen/setup.c: e820__update_table(&xen_e820_table);
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-29 01:00:35 +08:00
|
|
|
e820__update_table(e820_table);
|
2017-07-03 01:07:12 +08:00
|
|
|
e820__update_table(e820_table_kexec);
|
2017-01-29 05:27:28 +08:00
|
|
|
|
|
|
|
pr_info("extended physical RAM map:\n");
|
2017-01-28 21:24:02 +08:00
|
|
|
e820__print_table("reserve setup_data");
|
2017-01-28 20:25:45 +08:00
|
|
|
}
|
|
|
|
|
2017-01-28 20:37:17 +08: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-11 03:55:54 +08:00
|
|
|
{
|
|
|
|
if (userdef) {
|
x86/boot/e820: Simplify the e820__update_table() interface
The e820__update_table() parameters are pretty complex:
arch/x86/include/asm/e820/api.h:extern int e820__update_table(struct e820_entry *biosmap, int max_nr_map, u32 *pnr_map);
But 90% of the usage is trivial:
arch/x86/kernel/e820.c: if (e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries))
arch/x86/kernel/e820.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/kernel/e820.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/kernel/e820.c: if (e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries) < 0)
arch/x86/kernel/e820.c: e820__update_table(boot_params.e820_table, ARRAY_SIZE(boot_params.e820_table), &new_nr);
arch/x86/kernel/early-quirks.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/kernel/setup.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/kernel/setup.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/platform/efi/efi.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/xen/setup.c: e820__update_table(xen_e820_table.entries, ARRAY_SIZE(xen_e820_table.entries),
arch/x86/xen/setup.c: e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
arch/x86/xen/setup.c: e820__update_table(xen_e820_table.entries, ARRAY_SIZE(xen_e820_table.entries),
as it only uses an exiting struct e820_table's entries array, its size and
its current number of entries as input and output arguments.
Only one use is non-trivial:
arch/x86/kernel/e820.c: e820__update_table(boot_params.e820_table, ARRAY_SIZE(boot_params.e820_table), &new_nr);
... which call updates the E820 table in the zeropage in-situ, and the layout there does not
match that of 'struct e820_table' (in particular nr_entries is at a different offset,
hardcoded by the boot protocol).
Simplify all this by introducing a low level __e820__update_table() API that
the zeropage update call can use, and simplifying the main e820__update_table()
call signature down to:
int e820__update_table(struct e820_table *table);
This visibly simplifies all the call sites:
arch/x86/include/asm/e820/api.h:extern int e820__update_table(struct e820_table *table);
arch/x86/include/asm/e820/types.h: * call to e820__update_table() to remove duplicates. The allowance
arch/x86/kernel/e820.c: * The return value from e820__update_table() is zero if it
arch/x86/kernel/e820.c:int __init e820__update_table(struct e820_table *table)
arch/x86/kernel/e820.c: if (e820__update_table(e820_table))
arch/x86/kernel/e820.c: e820__update_table(e820_table_firmware);
arch/x86/kernel/e820.c: e820__update_table(e820_table);
arch/x86/kernel/e820.c: e820__update_table(e820_table);
arch/x86/kernel/e820.c: if (e820__update_table(e820_table) < 0)
arch/x86/kernel/early-quirks.c: e820__update_table(e820_table);
arch/x86/kernel/setup.c: e820__update_table(e820_table);
arch/x86/kernel/setup.c: e820__update_table(e820_table);
arch/x86/platform/efi/efi.c: e820__update_table(e820_table);
arch/x86/xen/setup.c: e820__update_table(&xen_e820_table);
arch/x86/xen/setup.c: e820__update_table(e820_table);
arch/x86/xen/setup.c: e820__update_table(&xen_e820_table);
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-29 01:00:35 +08:00
|
|
|
if (e820__update_table(e820_table) < 0)
|
2008-06-11 03:55:54 +08:00
|
|
|
early_panic("Invalid user supplied memory map");
|
|
|
|
|
2018-05-10 23:45:30 +08:00
|
|
|
pr_info("user-defined physical RAM map:\n");
|
2017-01-28 21:24:02 +08:00
|
|
|
e820__print_table("user");
|
2008-06-11 03:55:54 +08:00
|
|
|
}
|
|
|
|
}
|
2008-06-17 04:03:31 +08:00
|
|
|
|
2017-01-28 21:33:48 +08:00
|
|
|
static const char *__init e820_type_to_string(struct e820_entry *entry)
|
2008-06-27 19:12:55 +08:00
|
|
|
{
|
2017-01-28 21:33:48 +08:00
|
|
|
switch (entry->type) {
|
2017-01-29 00:09:33 +08:00
|
|
|
case E820_TYPE_RESERVED_KERN: /* Fall-through: */
|
|
|
|
case E820_TYPE_RAM: return "System RAM";
|
|
|
|
case E820_TYPE_ACPI: return "ACPI Tables";
|
|
|
|
case E820_TYPE_NVS: return "ACPI Non-volatile Storage";
|
|
|
|
case E820_TYPE_UNUSABLE: return "Unusable memory";
|
|
|
|
case E820_TYPE_PRAM: return "Persistent Memory (legacy)";
|
|
|
|
case E820_TYPE_PMEM: return "Persistent Memory";
|
2017-01-29 16:40:26 +08:00
|
|
|
case E820_TYPE_RESERVED: return "Reserved";
|
|
|
|
default: return "Unknown E820 type";
|
2008-06-27 19:12:55 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-01-28 21:33:48 +08:00
|
|
|
static unsigned long __init e820_type_to_iomem_type(struct e820_entry *entry)
|
2016-01-27 04:57:20 +08:00
|
|
|
{
|
2017-01-28 21:33:48 +08:00
|
|
|
switch (entry->type) {
|
2017-01-29 00:09:33 +08:00
|
|
|
case E820_TYPE_RESERVED_KERN: /* Fall-through: */
|
|
|
|
case E820_TYPE_RAM: return IORESOURCE_SYSTEM_RAM;
|
|
|
|
case E820_TYPE_ACPI: /* Fall-through: */
|
|
|
|
case E820_TYPE_NVS: /* Fall-through: */
|
|
|
|
case E820_TYPE_UNUSABLE: /* Fall-through: */
|
|
|
|
case E820_TYPE_PRAM: /* Fall-through: */
|
|
|
|
case E820_TYPE_PMEM: /* Fall-through: */
|
2017-01-29 16:40:26 +08:00
|
|
|
case E820_TYPE_RESERVED: /* Fall-through: */
|
2017-01-29 00:09:33 +08:00
|
|
|
default: return IORESOURCE_MEM;
|
2016-01-27 04:57:20 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-01-28 21:33:48 +08:00
|
|
|
static unsigned long __init e820_type_to_iores_desc(struct e820_entry *entry)
|
2016-01-27 04:57:20 +08:00
|
|
|
{
|
2017-01-28 21:33:48 +08:00
|
|
|
switch (entry->type) {
|
2017-01-29 00:09:33 +08:00
|
|
|
case E820_TYPE_ACPI: return IORES_DESC_ACPI_TABLES;
|
|
|
|
case E820_TYPE_NVS: return IORES_DESC_ACPI_NV_STORAGE;
|
|
|
|
case E820_TYPE_PMEM: return IORES_DESC_PERSISTENT_MEMORY;
|
|
|
|
case E820_TYPE_PRAM: return IORES_DESC_PERSISTENT_MEMORY_LEGACY;
|
|
|
|
case E820_TYPE_RESERVED_KERN: /* Fall-through: */
|
|
|
|
case E820_TYPE_RAM: /* Fall-through: */
|
|
|
|
case E820_TYPE_UNUSABLE: /* Fall-through: */
|
2017-01-29 16:40:26 +08:00
|
|
|
case E820_TYPE_RESERVED: /* Fall-through: */
|
2017-01-29 00:09:33 +08:00
|
|
|
default: return IORES_DESC_NONE;
|
2016-01-27 04:57:20 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-01-29 16:40:26 +08:00
|
|
|
static bool __init do_mark_busy(enum e820_type type, struct resource *res)
|
2015-04-04 00:05:28 +08: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) {
|
2017-01-29 00:09:33 +08:00
|
|
|
case E820_TYPE_RESERVED:
|
|
|
|
case E820_TYPE_PRAM:
|
|
|
|
case E820_TYPE_PMEM:
|
2015-04-04 00:05:28 +08:00
|
|
|
return false;
|
2017-01-29 16:40:26 +08:00
|
|
|
case E820_TYPE_RESERVED_KERN:
|
|
|
|
case E820_TYPE_RAM:
|
|
|
|
case E820_TYPE_ACPI:
|
|
|
|
case E820_TYPE_NVS:
|
|
|
|
case E820_TYPE_UNUSABLE:
|
2015-04-04 00:05:28 +08:00
|
|
|
default:
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-06-17 04:03:31 +08:00
|
|
|
/*
|
2017-01-28 18:13:08 +08:00
|
|
|
* Mark E820 reserved areas as busy for the resource manager:
|
2008-06-17 04:03:31 +08:00
|
|
|
*/
|
2017-01-28 18:13:08 +08:00
|
|
|
|
2008-08-29 14:09:23 +08:00
|
|
|
static struct resource __initdata *e820_res;
|
2017-01-28 18:13:08 +08:00
|
|
|
|
2017-01-29 05:41:14 +08:00
|
|
|
void __init e820__reserve_resources(void)
|
2008-06-17 04:03:31 +08:00
|
|
|
{
|
|
|
|
int i;
|
2008-08-29 04:52:25 +08:00
|
|
|
struct resource *res;
|
2008-08-29 14:09:23 +08:00
|
|
|
u64 end;
|
2008-06-17 04:03:31 +08:00
|
|
|
|
2017-01-28 21:33:48 +08:00
|
|
|
res = alloc_bootmem(sizeof(*res) * e820_table->nr_entries);
|
2008-08-29 04:52:25 +08:00
|
|
|
e820_res = res;
|
2017-01-28 21:33:48 +08:00
|
|
|
|
2017-01-27 21:06:21 +08:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
2017-01-28 21:33:48 +08:00
|
|
|
struct e820_entry *entry = e820_table->entries + i;
|
|
|
|
|
|
|
|
end = entry->addr + entry->size - 1;
|
2008-09-11 16:31:50 +08:00
|
|
|
if (end != (resource_size_t)end) {
|
2008-06-17 04:03:31 +08:00
|
|
|
res++;
|
|
|
|
continue;
|
|
|
|
}
|
2017-01-28 21:33:48 +08: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 14:09:23 +08:00
|
|
|
|
|
|
|
/*
|
2017-01-29 05:41:14 +08:00
|
|
|
* Don't register the region that could be conflicted with
|
|
|
|
* PCI device BAR resources and insert them later in
|
|
|
|
* pcibios_resource_survey():
|
2008-08-29 14:09:23 +08:00
|
|
|
*/
|
2017-01-28 21:33:48 +08: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-02 01:17:22 +08:00
|
|
|
res->flags |= IORESOURCE_BUSY;
|
2008-08-29 04:52:25 +08: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-02 01:17:22 +08:00
|
|
|
}
|
2008-06-17 04:03:31 +08:00
|
|
|
res++;
|
|
|
|
}
|
2008-06-27 19:12:55 +08:00
|
|
|
|
2017-07-03 01:07:32 +08:00
|
|
|
/* Expose the bootloader-provided memory layout to the sysfs. */
|
|
|
|
for (i = 0; i < e820_table_firmware->nr_entries; i++) {
|
|
|
|
struct e820_entry *entry = e820_table_firmware->entries + i;
|
2017-01-28 18:13:08 +08:00
|
|
|
|
2017-01-28 21:33:48 +08:00
|
|
|
firmware_map_add_early(entry->addr, entry->addr + entry->size, e820_type_to_string(entry));
|
2008-06-27 19:12:55 +08:00
|
|
|
}
|
2008-06-17 04:03:31 +08:00
|
|
|
}
|
|
|
|
|
2017-01-29 05:41:14 +08:00
|
|
|
/*
|
|
|
|
* How much should we pad the end of RAM, depending on where it is?
|
|
|
|
*/
|
2016-09-18 05:39:25 +08:00
|
|
|
static unsigned long __init ram_alignment(resource_size_t pos)
|
2009-05-06 23:06:44 +08: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-12 05:17:16 +08:00
|
|
|
/* To 64MB for anything above that */
|
|
|
|
return 64*1024*1024;
|
2009-05-06 23:06:44 +08:00
|
|
|
}
|
|
|
|
|
2009-07-02 03:32:18 +08:00
|
|
|
#define MAX_RESOURCE_SIZE ((resource_size_t)-1)
|
|
|
|
|
2017-01-29 05:41:14 +08:00
|
|
|
void __init e820__reserve_resources_late(void)
|
2008-08-29 04:52:25 +08:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
struct resource *res;
|
|
|
|
|
|
|
|
res = e820_res;
|
2017-01-27 21:06:21 +08:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
2008-08-29 14:09:23 +08: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-02 01:17:22 +08:00
|
|
|
insert_resource_expand_to_fit(&iomem_resource, res);
|
2008-08-29 04:52:25 +08:00
|
|
|
res++;
|
|
|
|
}
|
2009-05-06 23:06:44 +08:00
|
|
|
|
|
|
|
/*
|
2017-01-28 18:13:08 +08:00
|
|
|
* Try to bump up RAM regions to reasonable boundaries, to
|
2009-05-06 23:06:44 +08:00
|
|
|
* avoid stolen RAM:
|
|
|
|
*/
|
2017-01-27 21:06:21 +08:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
|
|
|
struct e820_entry *entry = &e820_table->entries[i];
|
2009-07-02 03:32:18 +08:00
|
|
|
u64 start, end;
|
2009-05-06 23:06:44 +08:00
|
|
|
|
2017-01-29 00:09:33 +08:00
|
|
|
if (entry->type != E820_TYPE_RAM)
|
2009-05-06 23:06:44 +08:00
|
|
|
continue;
|
2017-01-28 18:13:08 +08:00
|
|
|
|
2009-05-06 23:06:44 +08:00
|
|
|
start = entry->addr + entry->size;
|
2009-07-02 03:32:18 +08:00
|
|
|
end = round_up(start, ram_alignment(start)) - 1;
|
|
|
|
if (end > MAX_RESOURCE_SIZE)
|
|
|
|
end = MAX_RESOURCE_SIZE;
|
|
|
|
if (start >= end)
|
2009-05-06 23:06:44 +08:00
|
|
|
continue;
|
2017-01-28 18:13:08 +08:00
|
|
|
|
2017-02-01 01:53:34 +08:00
|
|
|
printk(KERN_DEBUG "e820: reserve RAM buffer [mem %#010llx-%#010llx]\n", start, end);
|
2017-01-28 18:13:08 +08:00
|
|
|
reserve_region_with_split(&iomem_resource, start, end, "RAM buffer");
|
2009-05-06 23:06:44 +08:00
|
|
|
}
|
2008-08-29 04:52:25 +08:00
|
|
|
}
|
|
|
|
|
2017-01-28 18:13:08 +08:00
|
|
|
/*
|
|
|
|
* Pass the firmware (bootloader) E820 map to the kernel and process it:
|
|
|
|
*/
|
2017-01-28 16:58:49 +08:00
|
|
|
char *__init e820__memory_setup_default(void)
|
2008-06-17 10:58:28 +08:00
|
|
|
{
|
|
|
|
char *who = "BIOS-e820";
|
2017-01-28 18:13:08 +08:00
|
|
|
|
2008-06-17 10:58:28 +08: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
|
|
|
|
*/
|
2017-01-28 18:13:08 +08:00
|
|
|
if (append_e820_table(boot_params.e820_table, boot_params.e820_entries) < 0) {
|
2008-06-19 08:27:08 +08:00
|
|
|
u64 mem_size;
|
2008-06-17 10:58:28 +08:00
|
|
|
|
2017-01-28 18:13:08 +08: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 10:58:28 +08: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 21:06:21 +08:00
|
|
|
e820_table->nr_entries = 0;
|
2017-01-29 00:09:33 +08:00
|
|
|
e820__range_add(0, LOWMEMSIZE(), E820_TYPE_RAM);
|
|
|
|
e820__range_add(HIGH_MEMORY, mem_size << 10, E820_TYPE_RAM);
|
2008-06-17 10:58:28 +08:00
|
|
|
}
|
|
|
|
|
2017-01-29 19:56:13 +08:00
|
|
|
/* We just appended a lot of ranges, sanitize the table: */
|
|
|
|
e820__update_table(e820_table);
|
|
|
|
|
2008-06-17 10:58:28 +08:00
|
|
|
return who;
|
|
|
|
}
|
|
|
|
|
2017-01-28 16:58:49 +08: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 10:58:28 +08:00
|
|
|
{
|
2008-07-04 02:35:37 +08:00
|
|
|
char *who;
|
|
|
|
|
2017-01-29 00:01:06 +08:00
|
|
|
/* This is a firmware interface ABI - make sure we don't break it: */
|
2017-01-29 19:56:13 +08:00
|
|
|
BUILD_BUG_ON(sizeof(struct boot_e820_entry) != 20);
|
2017-01-29 00:01:06 +08:00
|
|
|
|
2009-08-20 16:19:54 +08:00
|
|
|
who = x86_init.resources.memory_setup();
|
2017-01-28 18:13:08 +08:00
|
|
|
|
2017-07-03 01:07:12 +08:00
|
|
|
memcpy(e820_table_kexec, e820_table, sizeof(*e820_table_kexec));
|
2017-07-03 01:07:32 +08:00
|
|
|
memcpy(e820_table_firmware, e820_table, sizeof(*e820_table_firmware));
|
2017-01-28 18:13:08 +08:00
|
|
|
|
2018-05-10 23:45:30 +08:00
|
|
|
pr_info("BIOS-provided physical RAM map:\n");
|
2017-01-28 21:24:02 +08:00
|
|
|
e820__print_table(who);
|
2008-06-17 10:58:28 +08:00
|
|
|
}
|
2010-08-26 04:39:17 +08: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 18:37:42 +08:00
|
|
|
void __init e820__memblock_setup(void)
|
2010-08-26 04:39:17 +08:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
u64 end;
|
x86/e820: put !E820_TYPE_RAM regions into memblock.reserved
There is a kernel panic that is triggered when reading /proc/kpageflags
on the kernel booted with kernel parameter 'memmap=nn[KMG]!ss[KMG]':
BUG: unable to handle kernel paging request at fffffffffffffffe
PGD 9b20e067 P4D 9b20e067 PUD 9b210067 PMD 0
Oops: 0000 [#1] SMP PTI
CPU: 2 PID: 1728 Comm: page-types Not tainted 4.17.0-rc6-mm1-v4.17-rc6-180605-0816-00236-g2dfb086ef02c+ #160
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.fc28 04/01/2014
RIP: 0010:stable_page_flags+0x27/0x3c0
Code: 00 00 00 0f 1f 44 00 00 48 85 ff 0f 84 a0 03 00 00 41 54 55 49 89 fc 53 48 8b 57 08 48 8b 2f 48 8d 42 ff 83 e2 01 48 0f 44 c7 <48> 8b 00 f6 c4 01 0f 84 10 03 00 00 31 db 49 8b 54 24 08 4c 89 e7
RSP: 0018:ffffbbd44111fde0 EFLAGS: 00010202
RAX: fffffffffffffffe RBX: 00007fffffffeff9 RCX: 0000000000000000
RDX: 0000000000000001 RSI: 0000000000000202 RDI: ffffed1182fff5c0
RBP: ffffffffffffffff R08: 0000000000000001 R09: 0000000000000001
R10: ffffbbd44111fed8 R11: 0000000000000000 R12: ffffed1182fff5c0
R13: 00000000000bffd7 R14: 0000000002fff5c0 R15: ffffbbd44111ff10
FS: 00007efc4335a500(0000) GS:ffff93a5bfc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffffffffffffe CR3: 00000000b2a58000 CR4: 00000000001406e0
Call Trace:
kpageflags_read+0xc7/0x120
proc_reg_read+0x3c/0x60
__vfs_read+0x36/0x170
vfs_read+0x89/0x130
ksys_pread64+0x71/0x90
do_syscall_64+0x5b/0x160
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7efc42e75e23
Code: 09 00 ba 9f 01 00 00 e8 ab 81 f4 ff 66 2e 0f 1f 84 00 00 00 00 00 90 83 3d 29 0a 2d 00 00 75 13 49 89 ca b8 11 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 34 c3 48 83 ec 08 e8 db d3 01 00 48 89 04 24
According to kernel bisection, this problem became visible due to commit
f7f99100d8d9 ("mm: stop zeroing memory during allocation in vmemmap")
which changes how struct pages are initialized.
Memblock layout affects the pfn ranges covered by node/zone. Consider
that we have a VM with 2 NUMA nodes and each node has 4GB memory, and
the default (no memmap= given) memblock layout is like below:
MEMBLOCK configuration:
memory size = 0x00000001fff75c00 reserved size = 0x000000000300c000
memory.cnt = 0x4
memory[0x0] [0x0000000000001000-0x000000000009efff], 0x000000000009e000 bytes on node 0 flags: 0x0
memory[0x1] [0x0000000000100000-0x00000000bffd6fff], 0x00000000bfed7000 bytes on node 0 flags: 0x0
memory[0x2] [0x0000000100000000-0x000000013fffffff], 0x0000000040000000 bytes on node 0 flags: 0x0
memory[0x3] [0x0000000140000000-0x000000023fffffff], 0x0000000100000000 bytes on node 1 flags: 0x0
...
If you give memmap=1G!4G (so it just covers memory[0x2]),
the range [0x100000000-0x13fffffff] is gone:
MEMBLOCK configuration:
memory size = 0x00000001bff75c00 reserved size = 0x000000000300c000
memory.cnt = 0x3
memory[0x0] [0x0000000000001000-0x000000000009efff], 0x000000000009e000 bytes on node 0 flags: 0x0
memory[0x1] [0x0000000000100000-0x00000000bffd6fff], 0x00000000bfed7000 bytes on node 0 flags: 0x0
memory[0x2] [0x0000000140000000-0x000000023fffffff], 0x0000000100000000 bytes on node 1 flags: 0x0
...
This causes shrinking node 0's pfn range because it is calculated by the
address range of memblock.memory. So some of struct pages in the gap
range are left uninitialized.
We have a function zero_resv_unavail() which does zeroing the struct pages
within the reserved unavailable range (i.e. memblock.memory &&
!memblock.reserved). This patch utilizes it to cover all unavailable
ranges by putting them into memblock.reserved.
Link: http://lkml.kernel.org/r/20180615072947.GB23273@hori1.linux.bs1.fc.nec.co.jp
Fixes: f7f99100d8d9 ("mm: stop zeroing memory during allocation in vmemmap")
Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Tested-by: Oscar Salvador <osalvador@suse.de>
Tested-by: "Herton R. Krzesinski" <herton@redhat.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com>
Cc: Steven Sistare <steven.sistare@oracle.com>
Cc: Daniel Jordan <daniel.m.jordan@oracle.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-06-28 14:26:13 +08:00
|
|
|
u64 addr = 0;
|
2010-08-26 04:39:17 +08: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 18:37:42 +08: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-26 04:39:17 +08:00
|
|
|
*/
|
2011-12-09 02:22:08 +08:00
|
|
|
memblock_allow_resize();
|
2010-08-26 04:39:17 +08:00
|
|
|
|
2017-01-27 21:06:21 +08:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
2017-01-28 19:16:17 +08:00
|
|
|
struct e820_entry *entry = &e820_table->entries[i];
|
2010-08-26 04:39:17 +08:00
|
|
|
|
2017-01-28 19:16:17 +08:00
|
|
|
end = entry->addr + entry->size;
|
x86/e820: put !E820_TYPE_RAM regions into memblock.reserved
There is a kernel panic that is triggered when reading /proc/kpageflags
on the kernel booted with kernel parameter 'memmap=nn[KMG]!ss[KMG]':
BUG: unable to handle kernel paging request at fffffffffffffffe
PGD 9b20e067 P4D 9b20e067 PUD 9b210067 PMD 0
Oops: 0000 [#1] SMP PTI
CPU: 2 PID: 1728 Comm: page-types Not tainted 4.17.0-rc6-mm1-v4.17-rc6-180605-0816-00236-g2dfb086ef02c+ #160
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.fc28 04/01/2014
RIP: 0010:stable_page_flags+0x27/0x3c0
Code: 00 00 00 0f 1f 44 00 00 48 85 ff 0f 84 a0 03 00 00 41 54 55 49 89 fc 53 48 8b 57 08 48 8b 2f 48 8d 42 ff 83 e2 01 48 0f 44 c7 <48> 8b 00 f6 c4 01 0f 84 10 03 00 00 31 db 49 8b 54 24 08 4c 89 e7
RSP: 0018:ffffbbd44111fde0 EFLAGS: 00010202
RAX: fffffffffffffffe RBX: 00007fffffffeff9 RCX: 0000000000000000
RDX: 0000000000000001 RSI: 0000000000000202 RDI: ffffed1182fff5c0
RBP: ffffffffffffffff R08: 0000000000000001 R09: 0000000000000001
R10: ffffbbd44111fed8 R11: 0000000000000000 R12: ffffed1182fff5c0
R13: 00000000000bffd7 R14: 0000000002fff5c0 R15: ffffbbd44111ff10
FS: 00007efc4335a500(0000) GS:ffff93a5bfc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffffffffffffe CR3: 00000000b2a58000 CR4: 00000000001406e0
Call Trace:
kpageflags_read+0xc7/0x120
proc_reg_read+0x3c/0x60
__vfs_read+0x36/0x170
vfs_read+0x89/0x130
ksys_pread64+0x71/0x90
do_syscall_64+0x5b/0x160
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7efc42e75e23
Code: 09 00 ba 9f 01 00 00 e8 ab 81 f4 ff 66 2e 0f 1f 84 00 00 00 00 00 90 83 3d 29 0a 2d 00 00 75 13 49 89 ca b8 11 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 34 c3 48 83 ec 08 e8 db d3 01 00 48 89 04 24
According to kernel bisection, this problem became visible due to commit
f7f99100d8d9 ("mm: stop zeroing memory during allocation in vmemmap")
which changes how struct pages are initialized.
Memblock layout affects the pfn ranges covered by node/zone. Consider
that we have a VM with 2 NUMA nodes and each node has 4GB memory, and
the default (no memmap= given) memblock layout is like below:
MEMBLOCK configuration:
memory size = 0x00000001fff75c00 reserved size = 0x000000000300c000
memory.cnt = 0x4
memory[0x0] [0x0000000000001000-0x000000000009efff], 0x000000000009e000 bytes on node 0 flags: 0x0
memory[0x1] [0x0000000000100000-0x00000000bffd6fff], 0x00000000bfed7000 bytes on node 0 flags: 0x0
memory[0x2] [0x0000000100000000-0x000000013fffffff], 0x0000000040000000 bytes on node 0 flags: 0x0
memory[0x3] [0x0000000140000000-0x000000023fffffff], 0x0000000100000000 bytes on node 1 flags: 0x0
...
If you give memmap=1G!4G (so it just covers memory[0x2]),
the range [0x100000000-0x13fffffff] is gone:
MEMBLOCK configuration:
memory size = 0x00000001bff75c00 reserved size = 0x000000000300c000
memory.cnt = 0x3
memory[0x0] [0x0000000000001000-0x000000000009efff], 0x000000000009e000 bytes on node 0 flags: 0x0
memory[0x1] [0x0000000000100000-0x00000000bffd6fff], 0x00000000bfed7000 bytes on node 0 flags: 0x0
memory[0x2] [0x0000000140000000-0x000000023fffffff], 0x0000000100000000 bytes on node 1 flags: 0x0
...
This causes shrinking node 0's pfn range because it is calculated by the
address range of memblock.memory. So some of struct pages in the gap
range are left uninitialized.
We have a function zero_resv_unavail() which does zeroing the struct pages
within the reserved unavailable range (i.e. memblock.memory &&
!memblock.reserved). This patch utilizes it to cover all unavailable
ranges by putting them into memblock.reserved.
Link: http://lkml.kernel.org/r/20180615072947.GB23273@hori1.linux.bs1.fc.nec.co.jp
Fixes: f7f99100d8d9 ("mm: stop zeroing memory during allocation in vmemmap")
Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Tested-by: Oscar Salvador <osalvador@suse.de>
Tested-by: "Herton R. Krzesinski" <herton@redhat.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com>
Cc: Steven Sistare <steven.sistare@oracle.com>
Cc: Daniel Jordan <daniel.m.jordan@oracle.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-06-28 14:26:13 +08:00
|
|
|
if (addr < entry->addr)
|
|
|
|
memblock_reserve(addr, entry->addr - addr);
|
|
|
|
addr = end;
|
2010-08-26 04:39:17 +08:00
|
|
|
if (end != (resource_size_t)end)
|
|
|
|
continue;
|
|
|
|
|
x86/e820: put !E820_TYPE_RAM regions into memblock.reserved
There is a kernel panic that is triggered when reading /proc/kpageflags
on the kernel booted with kernel parameter 'memmap=nn[KMG]!ss[KMG]':
BUG: unable to handle kernel paging request at fffffffffffffffe
PGD 9b20e067 P4D 9b20e067 PUD 9b210067 PMD 0
Oops: 0000 [#1] SMP PTI
CPU: 2 PID: 1728 Comm: page-types Not tainted 4.17.0-rc6-mm1-v4.17-rc6-180605-0816-00236-g2dfb086ef02c+ #160
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.fc28 04/01/2014
RIP: 0010:stable_page_flags+0x27/0x3c0
Code: 00 00 00 0f 1f 44 00 00 48 85 ff 0f 84 a0 03 00 00 41 54 55 49 89 fc 53 48 8b 57 08 48 8b 2f 48 8d 42 ff 83 e2 01 48 0f 44 c7 <48> 8b 00 f6 c4 01 0f 84 10 03 00 00 31 db 49 8b 54 24 08 4c 89 e7
RSP: 0018:ffffbbd44111fde0 EFLAGS: 00010202
RAX: fffffffffffffffe RBX: 00007fffffffeff9 RCX: 0000000000000000
RDX: 0000000000000001 RSI: 0000000000000202 RDI: ffffed1182fff5c0
RBP: ffffffffffffffff R08: 0000000000000001 R09: 0000000000000001
R10: ffffbbd44111fed8 R11: 0000000000000000 R12: ffffed1182fff5c0
R13: 00000000000bffd7 R14: 0000000002fff5c0 R15: ffffbbd44111ff10
FS: 00007efc4335a500(0000) GS:ffff93a5bfc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffffffffffffe CR3: 00000000b2a58000 CR4: 00000000001406e0
Call Trace:
kpageflags_read+0xc7/0x120
proc_reg_read+0x3c/0x60
__vfs_read+0x36/0x170
vfs_read+0x89/0x130
ksys_pread64+0x71/0x90
do_syscall_64+0x5b/0x160
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7efc42e75e23
Code: 09 00 ba 9f 01 00 00 e8 ab 81 f4 ff 66 2e 0f 1f 84 00 00 00 00 00 90 83 3d 29 0a 2d 00 00 75 13 49 89 ca b8 11 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 34 c3 48 83 ec 08 e8 db d3 01 00 48 89 04 24
According to kernel bisection, this problem became visible due to commit
f7f99100d8d9 ("mm: stop zeroing memory during allocation in vmemmap")
which changes how struct pages are initialized.
Memblock layout affects the pfn ranges covered by node/zone. Consider
that we have a VM with 2 NUMA nodes and each node has 4GB memory, and
the default (no memmap= given) memblock layout is like below:
MEMBLOCK configuration:
memory size = 0x00000001fff75c00 reserved size = 0x000000000300c000
memory.cnt = 0x4
memory[0x0] [0x0000000000001000-0x000000000009efff], 0x000000000009e000 bytes on node 0 flags: 0x0
memory[0x1] [0x0000000000100000-0x00000000bffd6fff], 0x00000000bfed7000 bytes on node 0 flags: 0x0
memory[0x2] [0x0000000100000000-0x000000013fffffff], 0x0000000040000000 bytes on node 0 flags: 0x0
memory[0x3] [0x0000000140000000-0x000000023fffffff], 0x0000000100000000 bytes on node 1 flags: 0x0
...
If you give memmap=1G!4G (so it just covers memory[0x2]),
the range [0x100000000-0x13fffffff] is gone:
MEMBLOCK configuration:
memory size = 0x00000001bff75c00 reserved size = 0x000000000300c000
memory.cnt = 0x3
memory[0x0] [0x0000000000001000-0x000000000009efff], 0x000000000009e000 bytes on node 0 flags: 0x0
memory[0x1] [0x0000000000100000-0x00000000bffd6fff], 0x00000000bfed7000 bytes on node 0 flags: 0x0
memory[0x2] [0x0000000140000000-0x000000023fffffff], 0x0000000100000000 bytes on node 1 flags: 0x0
...
This causes shrinking node 0's pfn range because it is calculated by the
address range of memblock.memory. So some of struct pages in the gap
range are left uninitialized.
We have a function zero_resv_unavail() which does zeroing the struct pages
within the reserved unavailable range (i.e. memblock.memory &&
!memblock.reserved). This patch utilizes it to cover all unavailable
ranges by putting them into memblock.reserved.
Link: http://lkml.kernel.org/r/20180615072947.GB23273@hori1.linux.bs1.fc.nec.co.jp
Fixes: f7f99100d8d9 ("mm: stop zeroing memory during allocation in vmemmap")
Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Tested-by: Oscar Salvador <osalvador@suse.de>
Tested-by: "Herton R. Krzesinski" <herton@redhat.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com>
Cc: Steven Sistare <steven.sistare@oracle.com>
Cc: Daniel Jordan <daniel.m.jordan@oracle.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-06-28 14:26:13 +08:00
|
|
|
/*
|
|
|
|
* all !E820_TYPE_RAM ranges (including gap ranges) are put
|
|
|
|
* into memblock.reserved to make sure that struct pages in
|
|
|
|
* such regions are not left uninitialized after bootup.
|
|
|
|
*/
|
2017-01-29 00:09:33 +08:00
|
|
|
if (entry->type != E820_TYPE_RAM && entry->type != E820_TYPE_RESERVED_KERN)
|
x86/e820: put !E820_TYPE_RAM regions into memblock.reserved
There is a kernel panic that is triggered when reading /proc/kpageflags
on the kernel booted with kernel parameter 'memmap=nn[KMG]!ss[KMG]':
BUG: unable to handle kernel paging request at fffffffffffffffe
PGD 9b20e067 P4D 9b20e067 PUD 9b210067 PMD 0
Oops: 0000 [#1] SMP PTI
CPU: 2 PID: 1728 Comm: page-types Not tainted 4.17.0-rc6-mm1-v4.17-rc6-180605-0816-00236-g2dfb086ef02c+ #160
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.fc28 04/01/2014
RIP: 0010:stable_page_flags+0x27/0x3c0
Code: 00 00 00 0f 1f 44 00 00 48 85 ff 0f 84 a0 03 00 00 41 54 55 49 89 fc 53 48 8b 57 08 48 8b 2f 48 8d 42 ff 83 e2 01 48 0f 44 c7 <48> 8b 00 f6 c4 01 0f 84 10 03 00 00 31 db 49 8b 54 24 08 4c 89 e7
RSP: 0018:ffffbbd44111fde0 EFLAGS: 00010202
RAX: fffffffffffffffe RBX: 00007fffffffeff9 RCX: 0000000000000000
RDX: 0000000000000001 RSI: 0000000000000202 RDI: ffffed1182fff5c0
RBP: ffffffffffffffff R08: 0000000000000001 R09: 0000000000000001
R10: ffffbbd44111fed8 R11: 0000000000000000 R12: ffffed1182fff5c0
R13: 00000000000bffd7 R14: 0000000002fff5c0 R15: ffffbbd44111ff10
FS: 00007efc4335a500(0000) GS:ffff93a5bfc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffffffffffffe CR3: 00000000b2a58000 CR4: 00000000001406e0
Call Trace:
kpageflags_read+0xc7/0x120
proc_reg_read+0x3c/0x60
__vfs_read+0x36/0x170
vfs_read+0x89/0x130
ksys_pread64+0x71/0x90
do_syscall_64+0x5b/0x160
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7efc42e75e23
Code: 09 00 ba 9f 01 00 00 e8 ab 81 f4 ff 66 2e 0f 1f 84 00 00 00 00 00 90 83 3d 29 0a 2d 00 00 75 13 49 89 ca b8 11 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 34 c3 48 83 ec 08 e8 db d3 01 00 48 89 04 24
According to kernel bisection, this problem became visible due to commit
f7f99100d8d9 ("mm: stop zeroing memory during allocation in vmemmap")
which changes how struct pages are initialized.
Memblock layout affects the pfn ranges covered by node/zone. Consider
that we have a VM with 2 NUMA nodes and each node has 4GB memory, and
the default (no memmap= given) memblock layout is like below:
MEMBLOCK configuration:
memory size = 0x00000001fff75c00 reserved size = 0x000000000300c000
memory.cnt = 0x4
memory[0x0] [0x0000000000001000-0x000000000009efff], 0x000000000009e000 bytes on node 0 flags: 0x0
memory[0x1] [0x0000000000100000-0x00000000bffd6fff], 0x00000000bfed7000 bytes on node 0 flags: 0x0
memory[0x2] [0x0000000100000000-0x000000013fffffff], 0x0000000040000000 bytes on node 0 flags: 0x0
memory[0x3] [0x0000000140000000-0x000000023fffffff], 0x0000000100000000 bytes on node 1 flags: 0x0
...
If you give memmap=1G!4G (so it just covers memory[0x2]),
the range [0x100000000-0x13fffffff] is gone:
MEMBLOCK configuration:
memory size = 0x00000001bff75c00 reserved size = 0x000000000300c000
memory.cnt = 0x3
memory[0x0] [0x0000000000001000-0x000000000009efff], 0x000000000009e000 bytes on node 0 flags: 0x0
memory[0x1] [0x0000000000100000-0x00000000bffd6fff], 0x00000000bfed7000 bytes on node 0 flags: 0x0
memory[0x2] [0x0000000140000000-0x000000023fffffff], 0x0000000100000000 bytes on node 1 flags: 0x0
...
This causes shrinking node 0's pfn range because it is calculated by the
address range of memblock.memory. So some of struct pages in the gap
range are left uninitialized.
We have a function zero_resv_unavail() which does zeroing the struct pages
within the reserved unavailable range (i.e. memblock.memory &&
!memblock.reserved). This patch utilizes it to cover all unavailable
ranges by putting them into memblock.reserved.
Link: http://lkml.kernel.org/r/20180615072947.GB23273@hori1.linux.bs1.fc.nec.co.jp
Fixes: f7f99100d8d9 ("mm: stop zeroing memory during allocation in vmemmap")
Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Tested-by: Oscar Salvador <osalvador@suse.de>
Tested-by: "Herton R. Krzesinski" <herton@redhat.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com>
Cc: Steven Sistare <steven.sistare@oracle.com>
Cc: Daniel Jordan <daniel.m.jordan@oracle.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-06-28 14:26:13 +08:00
|
|
|
memblock_reserve(entry->addr, entry->size);
|
|
|
|
else
|
|
|
|
memblock_add(entry->addr, entry->size);
|
2010-08-26 04:39:17 +08: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 18:37:42 +08:00
|
|
|
/* Throw away partial pages: */
|
2012-10-23 07:35:18 +08:00
|
|
|
memblock_trim_memory(PAGE_SIZE);
|
|
|
|
|
2010-08-26 04:39:17 +08:00
|
|
|
memblock_dump_all();
|
|
|
|
}
|