2019-05-19 12:08:55 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2008-05-11 07:30:15 +00:00
|
|
|
/*
|
2017-01-28 10:13:08 +00:00
|
|
|
* Low level x86 E820 memory map handling functions.
|
2008-05-11 07:30:15 +00:00
|
|
|
*
|
2017-01-28 10:13:08 +00:00
|
|
|
* The firmware and bootloader passes us the "E820 table", which is the primary
|
|
|
|
* physical memory layout description available about x86 systems.
|
2008-05-11 07:30:15 +00:00
|
|
|
*
|
2017-01-28 10:13:08 +00:00
|
|
|
* The kernel takes the E820 memory layout and optionally modifies it with
|
|
|
|
* quirks and other tweaks, and feeds that into the generic Linux memory
|
|
|
|
* allocation code routines via a platform independent interface (memblock, etc.).
|
2008-05-11 07:30:15 +00:00
|
|
|
*/
|
2011-03-23 23:43:29 +00:00
|
|
|
#include <linux/crash_dump.h>
|
2018-10-30 22:09:49 +00:00
|
|
|
#include <linux/memblock.h>
|
2008-05-21 03:10:58 +00:00
|
|
|
#include <linux/suspend.h>
|
2011-01-07 00:43:44 +00:00
|
|
|
#include <linux/acpi.h>
|
2008-06-27 11:12:55 +00:00
|
|
|
#include <linux/firmware-map.h>
|
2011-11-15 22:46:50 +00:00
|
|
|
#include <linux/sort.h>
|
2019-02-14 10:42:39 +00:00
|
|
|
#include <linux/memory_hotplug.h>
|
2008-05-11 07:30:15 +00:00
|
|
|
|
2017-01-27 09:27:10 +00:00
|
|
|
#include <asm/e820/api.h>
|
2008-05-11 07:30:15 +00:00
|
|
|
#include <asm/setup.h>
|
|
|
|
|
2008-06-27 11:12:55 +00:00
|
|
|
/*
|
2017-07-02 17:07:32 +00:00
|
|
|
* We organize the E820 table into three main data structures:
|
2017-01-28 09:07:49 +00:00
|
|
|
*
|
2017-07-02 17:07:32 +00: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 09:07:49 +00:00
|
|
|
*
|
|
|
|
* - inform the user about the firmware's notion of memory layout
|
|
|
|
* via /sys/firmware/memmap
|
|
|
|
*
|
2021-04-20 12:57:39 +00:00
|
|
|
* - the hibernation code uses it to generate a kernel-independent CRC32
|
|
|
|
* checksum of the physical memory layout of a system.
|
2017-01-28 09:07:49 +00:00
|
|
|
*
|
2017-07-02 17:07:32 +00: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 10:13:08 +00:00
|
|
|
* - kexec, which is a bootloader in disguise, uses the original E820
|
2017-01-28 09:07:49 +00:00
|
|
|
* layout to pass to the kexec-ed kernel. This way the original kernel
|
2017-01-28 10:13:08 +00:00
|
|
|
* can have a restricted E820 map while the kexec()-ed kexec-kernel
|
2017-01-28 09:07:49 +00:00
|
|
|
* can have access to full memory - etc.
|
|
|
|
*
|
2017-01-28 10:13:08 +00:00
|
|
|
* - 'e820_table': this is the main E820 table that is massaged by the
|
2017-01-28 09:07:49 +00:00
|
|
|
* low level x86 platform code, or modified by boot parameters, before
|
|
|
|
* passed on to higher level MM layers.
|
|
|
|
*
|
2017-01-28 10:13:08 +00:00
|
|
|
* Once the E820 map has been converted to the standard Linux memory layout
|
2017-01-28 09:07:49 +00:00
|
|
|
* information its role stops - modifying it has no effect and does not get
|
2022-12-11 10:38:49 +00:00
|
|
|
* re-propagated. So its main role is a temporary bootstrap storage of firmware
|
2017-01-28 09:07:49 +00:00
|
|
|
* specific memory layout data during early bootup.
|
2008-06-27 11:12:55 +00:00
|
|
|
*/
|
2017-01-28 09:07:49 +00:00
|
|
|
static struct e820_table e820_table_init __initdata;
|
2017-07-02 17:07:12 +00:00
|
|
|
static struct e820_table e820_table_kexec_init __initdata;
|
2017-07-02 17:07:32 +00:00
|
|
|
static struct e820_table e820_table_firmware_init __initdata;
|
2017-01-28 09:07:49 +00:00
|
|
|
|
|
|
|
struct e820_table *e820_table __refdata = &e820_table_init;
|
2017-07-02 17:07:12 +00:00
|
|
|
struct e820_table *e820_table_kexec __refdata = &e820_table_kexec_init;
|
2017-07-02 17:07:32 +00:00
|
|
|
struct e820_table *e820_table_firmware __refdata = &e820_table_firmware_init;
|
2008-05-11 07:30:15 +00:00
|
|
|
|
|
|
|
/* For PCI or other memory-mapped resources */
|
|
|
|
unsigned long pci_mem_start = 0xaeedbabe;
|
|
|
|
#ifdef CONFIG_PCI
|
|
|
|
EXPORT_SYMBOL(pci_mem_start);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This function checks if any part of the range <start,end> is mapped
|
|
|
|
* with type.
|
|
|
|
*/
|
2019-01-31 20:24:44 +00:00
|
|
|
static bool _e820__mapped_any(struct e820_table *table,
|
|
|
|
u64 start, u64 end, enum e820_type type)
|
2008-05-11 07:30:15 +00:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2019-01-31 20:24:44 +00:00
|
|
|
for (i = 0; i < table->nr_entries; i++) {
|
|
|
|
struct e820_entry *entry = &table->entries[i];
|
2008-05-11 07:30:15 +00:00
|
|
|
|
2017-01-28 11:16:17 +00:00
|
|
|
if (type && entry->type != type)
|
2008-05-11 07:30:15 +00:00
|
|
|
continue;
|
2017-01-28 11:16:17 +00:00
|
|
|
if (entry->addr >= end || entry->addr + entry->size <= start)
|
2008-05-11 07:30:15 +00:00
|
|
|
continue;
|
2019-07-15 02:47:09 +00:00
|
|
|
return true;
|
2008-05-11 07:30:15 +00:00
|
|
|
}
|
2019-07-15 02:47:09 +00:00
|
|
|
return false;
|
2008-05-11 07:30:15 +00:00
|
|
|
}
|
2019-01-31 20:24:44 +00:00
|
|
|
|
|
|
|
bool e820__mapped_raw_any(u64 start, u64 end, enum e820_type type)
|
|
|
|
{
|
|
|
|
return _e820__mapped_any(e820_table_firmware, start, end, type);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(e820__mapped_raw_any);
|
|
|
|
|
|
|
|
bool e820__mapped_any(u64 start, u64 end, enum e820_type type)
|
|
|
|
{
|
|
|
|
return _e820__mapped_any(e820_table, start, end, type);
|
|
|
|
}
|
2017-01-28 13:14:25 +00:00
|
|
|
EXPORT_SYMBOL_GPL(e820__mapped_any);
|
2008-05-11 07:30:15 +00:00
|
|
|
|
|
|
|
/*
|
2017-01-28 10:13:08 +00:00
|
|
|
* This function checks if the entire <start,end> range is mapped with 'type'.
|
2008-05-11 07:30:15 +00:00
|
|
|
*
|
2017-01-28 10:13:08 +00:00
|
|
|
* Note: this function only works correctly once the E820 table is sorted and
|
|
|
|
* not-overlapping (at least for the range specified), which is the case normally.
|
2008-05-11 07:30:15 +00:00
|
|
|
*/
|
2017-07-17 21:10:12 +00:00
|
|
|
static struct e820_entry *__e820__mapped_all(u64 start, u64 end,
|
|
|
|
enum e820_type type)
|
2008-05-11 07:30:15 +00:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2017-01-27 13:06:21 +00:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
2017-01-28 11:16:17 +00:00
|
|
|
struct e820_entry *entry = &e820_table->entries[i];
|
2008-05-11 07:30:15 +00:00
|
|
|
|
2017-01-28 11:16:17 +00:00
|
|
|
if (type && entry->type != type)
|
2008-05-11 07:30:15 +00:00
|
|
|
continue;
|
2017-01-28 10:13:08 +00:00
|
|
|
|
|
|
|
/* Is the region (part) in overlap with the current region? */
|
2017-01-28 11:16:17 +00:00
|
|
|
if (entry->addr >= end || entry->addr + entry->size <= start)
|
2008-05-11 07:30:15 +00:00
|
|
|
continue;
|
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/*
|
|
|
|
* If the region is at the beginning of <start,end> we move
|
|
|
|
* 'start' to the end of the region since it's ok until there
|
2008-05-11 07:30:15 +00:00
|
|
|
*/
|
2017-01-28 11:16:17 +00:00
|
|
|
if (entry->addr <= start)
|
|
|
|
start = entry->addr + entry->size;
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2008-05-11 07:30:15 +00:00
|
|
|
/*
|
2017-01-28 10:13:08 +00:00
|
|
|
* If 'start' is now at or beyond 'end', we're done, full
|
|
|
|
* coverage of the desired range exists:
|
2008-05-11 07:30:15 +00:00
|
|
|
*/
|
|
|
|
if (start >= end)
|
2017-07-17 21:10:12 +00:00
|
|
|
return entry;
|
2008-05-11 07:30:15 +00:00
|
|
|
}
|
2017-07-17 21:10:12 +00: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 07:30:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2017-01-28 10:13:08 +00:00
|
|
|
* Add a memory region to the kernel E820 map.
|
2008-05-11 07:30:15 +00:00
|
|
|
*/
|
2017-01-28 15:52:34 +00:00
|
|
|
static void __init __e820__range_add(struct e820_table *table, u64 start, u64 size, enum e820_type type)
|
2008-05-11 07:30:15 +00:00
|
|
|
{
|
2017-01-27 13:06:21 +00:00
|
|
|
int x = table->nr_entries;
|
2008-05-11 07:30:15 +00:00
|
|
|
|
2017-01-27 13:06:21 +00:00
|
|
|
if (x >= ARRAY_SIZE(table->entries)) {
|
2018-05-10 15:45:30 +00:00
|
|
|
pr_err("too many entries; ignoring [mem %#010llx-%#010llx]\n",
|
|
|
|
start, start + size - 1);
|
2008-05-11 07:30:15 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2017-01-27 13:06:21 +00:00
|
|
|
table->entries[x].addr = start;
|
|
|
|
table->entries[x].size = size;
|
|
|
|
table->entries[x].type = type;
|
|
|
|
table->nr_entries++;
|
2009-03-13 04:35:18 +00:00
|
|
|
}
|
|
|
|
|
2017-01-28 15:52:34 +00:00
|
|
|
void __init e820__range_add(u64 start, u64 size, enum e820_type type)
|
2009-03-13 04:35:18 +00:00
|
|
|
{
|
x86/boot/e820: Create coherent API function names for E820 range operations
We have these three related functions:
extern void e820_add_region(u64 start, u64 size, int type);
extern u64 e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);
But it's not clear from the naming that they are 3 operations based around the
same 'memory range' concept. Rename them to better signal this, and move
the prototypes next to each other:
extern void e820__range_add (u64 start, u64 size, int type);
extern u64 e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);
Note that this improved organization of the functions shows another problem that was easy
to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
will be fixed in a separate patch.
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 13:19:36 +00:00
|
|
|
__e820__range_add(e820_table, start, size, type);
|
2008-05-11 07:30:15 +00:00
|
|
|
}
|
|
|
|
|
2017-01-28 15:52:34 +00:00
|
|
|
static void __init e820_print_type(enum e820_type type)
|
2009-03-15 07:59:19 +00:00
|
|
|
{
|
|
|
|
switch (type) {
|
2017-01-28 16:09:33 +00:00
|
|
|
case E820_TYPE_RAM: /* Fall through: */
|
|
|
|
case E820_TYPE_RESERVED_KERN: pr_cont("usable"); break;
|
|
|
|
case E820_TYPE_RESERVED: pr_cont("reserved"); break;
|
2019-11-07 01:43:16 +00:00
|
|
|
case E820_TYPE_SOFT_RESERVED: pr_cont("soft reserved"); break;
|
2017-01-28 16:09:33 +00:00
|
|
|
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 11:27:45 +00:00
|
|
|
default: pr_cont("type %u", type); break;
|
2009-03-15 07:59:19 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-01-28 13:24:02 +00:00
|
|
|
void __init e820__print_table(char *who)
|
2008-05-11 07:30:15 +00:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2017-01-27 13:06:21 +00:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
2018-05-10 15:45:30 +00: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 10:13:08 +00:00
|
|
|
|
2017-01-27 13:06:21 +00:00
|
|
|
e820_print_type(e820_table->entries[i].type);
|
2017-01-28 11:27:45 +00:00
|
|
|
pr_cont("\n");
|
2008-05-11 07:30:15 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2017-01-28 17:35:24 +00:00
|
|
|
* Sanitize an E820 map.
|
2008-05-11 07:30:15 +00:00
|
|
|
*
|
2017-01-28 17:35:24 +00:00
|
|
|
* Some E820 layouts include overlapping entries. The following
|
2017-01-28 10:13:08 +00:00
|
|
|
* replaces the original E820 map with a new one, removing overlaps,
|
2008-05-14 15:15:52 +00:00
|
|
|
* and resolving conflicting memory types in favor of highest
|
|
|
|
* numbered type.
|
2008-05-11 07:30:15 +00:00
|
|
|
*
|
2017-01-28 17:35:24 +00: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 10:13:08 +00:00
|
|
|
* On return, the resulting sanitized E820 map entries will be in
|
2017-01-28 17:35:24 +00:00
|
|
|
* overwritten in the same location, starting at 'entries'.
|
2008-05-14 15:15:52 +00:00
|
|
|
*
|
2017-01-28 17:35:24 +00: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 15:15:52 +00:00
|
|
|
*
|
2017-01-28 13:09:20 +00:00
|
|
|
* The return value from e820__update_table() is zero if it
|
2008-05-14 15:15:52 +00:00
|
|
|
* successfully 'sanitized' the map entries passed in, and is -1
|
|
|
|
* if it did nothing, which can happen if either of (1) it was
|
|
|
|
* only passed one map entry, or (2) any of the input map entries
|
|
|
|
* were invalid (start + size < start, meaning that the size was
|
|
|
|
* so big the described memory range wrapped around through zero.)
|
|
|
|
*
|
|
|
|
* Visually we're performing the following
|
|
|
|
* (1,2,3,4 = memory types)...
|
|
|
|
*
|
|
|
|
* Sample memory map (w/overlaps):
|
|
|
|
* ____22__________________
|
|
|
|
* ______________________4_
|
|
|
|
* ____1111________________
|
|
|
|
* _44_____________________
|
|
|
|
* 11111111________________
|
|
|
|
* ____________________33__
|
|
|
|
* ___________44___________
|
|
|
|
* __________33333_________
|
|
|
|
* ______________22________
|
|
|
|
* ___________________2222_
|
|
|
|
* _________111111111______
|
|
|
|
* _____________________11_
|
|
|
|
* _________________4______
|
|
|
|
*
|
|
|
|
* Sanitized equivalent (no overlap):
|
|
|
|
* 1_______________________
|
|
|
|
* _44_____________________
|
|
|
|
* ___1____________________
|
|
|
|
* ____22__________________
|
|
|
|
* ______11________________
|
|
|
|
* _________1______________
|
|
|
|
* __________3_____________
|
|
|
|
* ___________44___________
|
|
|
|
* _____________33_________
|
|
|
|
* _______________2________
|
|
|
|
* ________________1_______
|
|
|
|
* _________________4______
|
|
|
|
* ___________________2____
|
|
|
|
* ____________________33__
|
|
|
|
* ______________________4_
|
2008-05-11 07:30:15 +00:00
|
|
|
*/
|
2011-11-15 22:46:50 +00:00
|
|
|
struct change_member {
|
2017-01-28 17:35:24 +00:00
|
|
|
/* Pointer to the original entry: */
|
|
|
|
struct e820_entry *entry;
|
2017-01-28 10:13:08 +00:00
|
|
|
/* Address for this change point: */
|
|
|
|
unsigned long long addr;
|
2011-11-15 22:46:50 +00:00
|
|
|
};
|
|
|
|
|
2017-01-30 08:24:39 +00: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-15 22:46:50 +00:00
|
|
|
static int __init cpcompare(const void *a, const void *b)
|
|
|
|
{
|
|
|
|
struct change_member * const *app = a, * const *bpp = b;
|
|
|
|
const struct change_member *ap = *app, *bp = *bpp;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Inputs are pointers to two elements of change_point[]. If their
|
2017-01-28 10:13:08 +00:00
|
|
|
* addresses are not equal, their difference dominates. If the addresses
|
2011-11-15 22:46:50 +00:00
|
|
|
* are equal, then consider one that represents the end of its region
|
|
|
|
* to be greater than one that does not.
|
|
|
|
*/
|
|
|
|
if (ap->addr != bp->addr)
|
|
|
|
return ap->addr > bp->addr ? 1 : -1;
|
|
|
|
|
2017-01-28 17:35:24 +00:00
|
|
|
return (ap->addr != ap->entry->addr) - (bp->addr != bp->entry->addr);
|
2011-11-15 22:46:50 +00:00
|
|
|
}
|
2008-05-14 15:15:52 +00:00
|
|
|
|
2020-10-13 23:49:08 +00:00
|
|
|
static bool e820_nomerge(enum e820_type type)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* These types may indicate distinct platform ranges aligned to
|
|
|
|
* numa node, protection domain, performance domain, or other
|
|
|
|
* boundaries. Do not merge them.
|
|
|
|
*/
|
|
|
|
if (type == E820_TYPE_PRAM)
|
|
|
|
return true;
|
|
|
|
if (type == E820_TYPE_SOFT_RESERVED)
|
|
|
|
return true;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2017-01-30 08:24:39 +00:00
|
|
|
int __init e820__update_table(struct e820_table *table)
|
2008-05-11 07:30:15 +00:00
|
|
|
{
|
2017-01-30 08:24:39 +00:00
|
|
|
struct e820_entry *entries = table->entries;
|
|
|
|
u32 max_nr_entries = ARRAY_SIZE(table->entries);
|
2017-01-28 15:52:34 +00:00
|
|
|
enum e820_type current_type, last_type;
|
2008-05-11 07:30:15 +00:00
|
|
|
unsigned long long last_addr;
|
2017-01-30 08:24:39 +00:00
|
|
|
u32 new_nr_entries, overlap_entries;
|
|
|
|
u32 i, chg_idx, chg_nr;
|
2008-05-11 07:30:15 +00:00
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/* If there's only one memory region, don't bother: */
|
2017-01-30 08:24:39 +00:00
|
|
|
if (table->nr_entries < 2)
|
2008-05-11 07:30:15 +00:00
|
|
|
return -1;
|
|
|
|
|
2017-01-30 08:24:39 +00:00
|
|
|
BUG_ON(table->nr_entries > max_nr_entries);
|
2008-05-11 07:30:15 +00:00
|
|
|
|
2017-01-28 17:35:24 +00:00
|
|
|
/* Bail out if we find any unreasonable addresses in the map: */
|
2017-01-30 08:24:39 +00:00
|
|
|
for (i = 0; i < table->nr_entries; i++) {
|
2017-01-28 17:35:24 +00:00
|
|
|
if (entries[i].addr + entries[i].size < entries[i].addr)
|
2008-05-11 07:30:15 +00:00
|
|
|
return -1;
|
2017-01-28 10:13:08 +00:00
|
|
|
}
|
2008-05-11 07:30:15 +00:00
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/* Create pointers for initial change-point information (for sorting): */
|
2017-01-30 08:24:39 +00:00
|
|
|
for (i = 0; i < 2 * table->nr_entries; i++)
|
2008-05-11 07:30:15 +00:00
|
|
|
change_point[i] = &change_point_list[i];
|
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/*
|
|
|
|
* Record all known change-points (starting and ending addresses),
|
|
|
|
* omitting empty memory regions:
|
|
|
|
*/
|
2017-01-30 08:24:39 +00:00
|
|
|
chg_idx = 0;
|
|
|
|
for (i = 0; i < table->nr_entries; i++) {
|
2017-01-28 17:35:24 +00:00
|
|
|
if (entries[i].size != 0) {
|
2017-01-30 08:24:39 +00: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 07:30:15 +00:00
|
|
|
}
|
|
|
|
}
|
2017-01-30 08:24:39 +00:00
|
|
|
chg_nr = chg_idx;
|
2008-05-11 07:30:15 +00:00
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/* Sort change-point list by memory addresses (low -> high): */
|
2017-01-28 16:48:08 +00:00
|
|
|
sort(change_point, chg_nr, sizeof(*change_point), cpcompare, NULL);
|
2008-05-11 07:30:15 +00:00
|
|
|
|
2017-01-28 17:35:24 +00:00
|
|
|
/* Create a new memory map, removing overlaps: */
|
2017-01-28 10:13:08 +00:00
|
|
|
overlap_entries = 0; /* Number of entries in the overlap table */
|
2017-01-28 17:35:24 +00:00
|
|
|
new_nr_entries = 0; /* Index for creating new map entries */
|
2017-01-28 10:13:08 +00:00
|
|
|
last_type = 0; /* Start with undefined memory type */
|
|
|
|
last_addr = 0; /* Start with 0 as last starting address */
|
2008-05-11 07:30:15 +00:00
|
|
|
|
2017-01-28 17:35:24 +00:00
|
|
|
/* Loop through change-points, determining effect on the new map: */
|
2017-01-30 08:24:39 +00:00
|
|
|
for (chg_idx = 0; chg_idx < chg_nr; chg_idx++) {
|
2017-01-28 17:35:24 +00:00
|
|
|
/* Keep track of all overlapping entries */
|
2017-01-30 08:24:39 +00:00
|
|
|
if (change_point[chg_idx]->addr == change_point[chg_idx]->entry->addr) {
|
2017-01-28 10:13:08 +00:00
|
|
|
/* Add map entry to overlap list (> 1 entry implies an overlap) */
|
2017-01-30 08:24:39 +00:00
|
|
|
overlap_list[overlap_entries++] = change_point[chg_idx]->entry;
|
2008-05-11 07:30:15 +00:00
|
|
|
} else {
|
2017-01-28 10:13:08 +00:00
|
|
|
/* Remove entry from list (order independent, so swap with last): */
|
2008-05-11 07:30:15 +00:00
|
|
|
for (i = 0; i < overlap_entries; i++) {
|
2017-01-30 08:24:39 +00:00
|
|
|
if (overlap_list[i] == change_point[chg_idx]->entry)
|
2017-01-28 10:13:08 +00:00
|
|
|
overlap_list[i] = overlap_list[overlap_entries-1];
|
2008-05-11 07:30:15 +00:00
|
|
|
}
|
|
|
|
overlap_entries--;
|
|
|
|
}
|
|
|
|
/*
|
2017-01-28 10:13:08 +00:00
|
|
|
* If there are overlapping entries, decide which
|
2008-05-11 07:30:15 +00:00
|
|
|
* "type" to use (larger value takes precedence --
|
|
|
|
* 1=usable, 2,3,4,4+=unusable)
|
|
|
|
*/
|
|
|
|
current_type = 0;
|
2017-01-28 10:13:08 +00:00
|
|
|
for (i = 0; i < overlap_entries; i++) {
|
2008-05-11 07:30:15 +00:00
|
|
|
if (overlap_list[i]->type > current_type)
|
|
|
|
current_type = overlap_list[i]->type;
|
2017-01-28 10:13:08 +00:00
|
|
|
}
|
|
|
|
|
2017-01-28 17:35:24 +00:00
|
|
|
/* Continue building up new map based on this information: */
|
2020-10-13 23:49:08 +00:00
|
|
|
if (current_type != last_type || e820_nomerge(current_type)) {
|
2022-06-01 12:29:14 +00:00
|
|
|
if (last_type) {
|
2017-01-30 08:24:39 +00:00
|
|
|
new_entries[new_nr_entries].size = change_point[chg_idx]->addr - last_addr;
|
2017-01-28 10:13:08 +00:00
|
|
|
/* Move forward only if the new size was non-zero: */
|
2017-01-28 17:35:24 +00: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 07:30:15 +00:00
|
|
|
break;
|
|
|
|
}
|
2022-06-01 12:29:14 +00:00
|
|
|
if (current_type) {
|
2017-01-30 08:24:39 +00:00
|
|
|
new_entries[new_nr_entries].addr = change_point[chg_idx]->addr;
|
2017-01-28 17:35:24 +00:00
|
|
|
new_entries[new_nr_entries].type = current_type;
|
2017-01-30 08:24:39 +00:00
|
|
|
last_addr = change_point[chg_idx]->addr;
|
2008-05-11 07:30:15 +00:00
|
|
|
}
|
|
|
|
last_type = current_type;
|
|
|
|
}
|
|
|
|
}
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2017-01-28 17:35:24 +00:00
|
|
|
/* Copy the new entries into the original location: */
|
2017-01-30 08:24:39 +00:00
|
|
|
memcpy(entries, new_entries, new_nr_entries*sizeof(*entries));
|
|
|
|
table->nr_entries = new_nr_entries;
|
2008-05-11 07:30:15 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-01-29 11:56:13 +00:00
|
|
|
static int __init __append_e820_table(struct boot_e820_entry *entries, u32 nr_entries)
|
2008-06-11 03:33:39 +00:00
|
|
|
{
|
2017-01-29 11:56:13 +00:00
|
|
|
struct boot_e820_entry *entry = entries;
|
2017-01-28 17:35:24 +00:00
|
|
|
|
|
|
|
while (nr_entries) {
|
|
|
|
u64 start = entry->addr;
|
|
|
|
u64 size = entry->size;
|
2016-08-20 01:40:13 +00:00
|
|
|
u64 end = start + size - 1;
|
2017-01-28 17:35:24 +00:00
|
|
|
u32 type = entry->type;
|
2008-06-11 03:33:39 +00:00
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/* Ignore the entry on 64-bit overflow: */
|
2016-08-20 01:40:13 +00:00
|
|
|
if (start > end && likely(size))
|
2008-06-11 03:33:39 +00:00
|
|
|
return -1;
|
|
|
|
|
x86/boot/e820: Create coherent API function names for E820 range operations
We have these three related functions:
extern void e820_add_region(u64 start, u64 size, int type);
extern u64 e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);
But it's not clear from the naming that they are 3 operations based around the
same 'memory range' concept. Rename them to better signal this, and move
the prototypes next to each other:
extern void e820__range_add (u64 start, u64 size, int type);
extern u64 e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);
Note that this improved organization of the functions shows another problem that was easy
to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
will be fixed in a separate patch.
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 13:19:36 +00:00
|
|
|
e820__range_add(start, size, type);
|
2008-06-11 03:33:39 +00:00
|
|
|
|
2017-01-28 17:35:24 +00:00
|
|
|
entry++;
|
|
|
|
nr_entries--;
|
2008-06-11 03:33:39 +00:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-05-11 07:30:15 +00:00
|
|
|
/*
|
2017-01-28 10:13:08 +00:00
|
|
|
* Copy the BIOS E820 map into a safe place.
|
2008-05-11 07:30:15 +00:00
|
|
|
*
|
|
|
|
* Sanity-check it while we're at it..
|
|
|
|
*
|
|
|
|
* If we're lucky and live on a modern system, the setup code
|
|
|
|
* will have given us a memory map that we can use to properly
|
|
|
|
* set up memory. If we aren't, we'll fake a memory map.
|
|
|
|
*/
|
2017-01-29 11:56:13 +00:00
|
|
|
static int __init append_e820_table(struct boot_e820_entry *entries, u32 nr_entries)
|
2008-05-11 07:30:15 +00:00
|
|
|
{
|
|
|
|
/* Only one memory region (or negative)? Ignore it */
|
2017-01-28 17:35:24 +00:00
|
|
|
if (nr_entries < 2)
|
2008-05-11 07:30:15 +00:00
|
|
|
return -1;
|
|
|
|
|
2017-01-28 17:35:24 +00:00
|
|
|
return __append_e820_table(entries, nr_entries);
|
2008-05-11 07:30:15 +00:00
|
|
|
}
|
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
static u64 __init
|
2017-01-28 15:52:34 +00: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 07:30:15 +00:00
|
|
|
{
|
2009-03-13 05:36:01 +00:00
|
|
|
u64 end;
|
2009-03-13 04:35:18 +00:00
|
|
|
unsigned int i;
|
2008-05-11 07:30:15 +00:00
|
|
|
u64 real_updated_size = 0;
|
|
|
|
|
|
|
|
BUG_ON(old_type == new_type);
|
|
|
|
|
2008-06-24 21:58:38 +00:00
|
|
|
if (size > (ULLONG_MAX - start))
|
|
|
|
size = ULLONG_MAX - start;
|
|
|
|
|
2009-03-13 05:36:01 +00:00
|
|
|
end = start + size;
|
2017-01-31 17:53:34 +00:00
|
|
|
printk(KERN_DEBUG "e820: update [mem %#010Lx-%#010Lx] ", start, end - 1);
|
2009-03-15 07:59:19 +00:00
|
|
|
e820_print_type(old_type);
|
2017-01-28 11:27:45 +00:00
|
|
|
pr_cont(" ==> ");
|
2009-03-15 07:59:19 +00:00
|
|
|
e820_print_type(new_type);
|
2017-01-28 11:27:45 +00:00
|
|
|
pr_cont("\n");
|
2009-03-15 07:59:19 +00:00
|
|
|
|
2017-01-27 13:06:21 +00:00
|
|
|
for (i = 0; i < table->nr_entries; i++) {
|
2017-01-28 11:16:17 +00:00
|
|
|
struct e820_entry *entry = &table->entries[i];
|
2008-05-11 07:30:15 +00:00
|
|
|
u64 final_start, final_end;
|
2017-01-28 11:16:17 +00:00
|
|
|
u64 entry_end;
|
2009-03-13 05:36:01 +00:00
|
|
|
|
2017-01-28 11:16:17 +00:00
|
|
|
if (entry->type != old_type)
|
2008-05-11 07:30:15 +00:00
|
|
|
continue;
|
2009-03-13 05:36:01 +00:00
|
|
|
|
2017-01-28 11:16:17 +00:00
|
|
|
entry_end = entry->addr + entry->size;
|
2017-01-28 10:13:08 +00:00
|
|
|
|
|
|
|
/* Completely covered by new range? */
|
2017-01-28 11:16:17 +00:00
|
|
|
if (entry->addr >= start && entry_end <= end) {
|
|
|
|
entry->type = new_type;
|
|
|
|
real_updated_size += entry->size;
|
2008-05-11 07:30:15 +00:00
|
|
|
continue;
|
|
|
|
}
|
2009-03-13 05:36:01 +00:00
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/* New range is completely covered? */
|
2017-01-28 11:16:17 +00:00
|
|
|
if (entry->addr < start && entry_end > end) {
|
x86/boot/e820: Create coherent API function names for E820 range operations
We have these three related functions:
extern void e820_add_region(u64 start, u64 size, int type);
extern u64 e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);
But it's not clear from the naming that they are 3 operations based around the
same 'memory range' concept. Rename them to better signal this, and move
the prototypes next to each other:
extern void e820__range_add (u64 start, u64 size, int type);
extern u64 e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);
Note that this improved organization of the functions shows another problem that was easy
to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
will be fixed in a separate patch.
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 13:19:36 +00:00
|
|
|
__e820__range_add(table, start, size, new_type);
|
|
|
|
__e820__range_add(table, end, entry_end - end, entry->type);
|
2017-01-28 11:16:17 +00:00
|
|
|
entry->size = start - entry->addr;
|
2009-03-13 05:36:01 +00:00
|
|
|
real_updated_size += size;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/* Partially covered: */
|
2017-01-28 11:16:17 +00:00
|
|
|
final_start = max(start, entry->addr);
|
|
|
|
final_end = min(end, entry_end);
|
2008-05-11 07:30:15 +00:00
|
|
|
if (final_start >= final_end)
|
|
|
|
continue;
|
2009-03-12 13:07:23 +00:00
|
|
|
|
x86/boot/e820: Create coherent API function names for E820 range operations
We have these three related functions:
extern void e820_add_region(u64 start, u64 size, int type);
extern u64 e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);
But it's not clear from the naming that they are 3 operations based around the
same 'memory range' concept. Rename them to better signal this, and move
the prototypes next to each other:
extern void e820__range_add (u64 start, u64 size, int type);
extern u64 e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);
Note that this improved organization of the functions shows another problem that was easy
to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
will be fixed in a separate patch.
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 13:19:36 +00:00
|
|
|
__e820__range_add(table, final_start, final_end - final_start, new_type);
|
2009-03-12 13:07:23 +00:00
|
|
|
|
2008-05-11 07:30:15 +00:00
|
|
|
real_updated_size += final_end - final_start;
|
2008-06-24 21:55:32 +00:00
|
|
|
|
2009-03-13 04:35:18 +00:00
|
|
|
/*
|
2017-01-28 10:13:08 +00:00
|
|
|
* Left range could be head or tail, so need to update
|
|
|
|
* its size first:
|
2009-03-13 04:35:18 +00:00
|
|
|
*/
|
2017-01-28 11:16:17 +00:00
|
|
|
entry->size -= final_end - final_start;
|
|
|
|
if (entry->addr < final_start)
|
2008-06-24 21:55:32 +00:00
|
|
|
continue;
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2017-01-28 11:16:17 +00:00
|
|
|
entry->addr = final_end;
|
2008-05-11 07:30:15 +00:00
|
|
|
}
|
|
|
|
return real_updated_size;
|
|
|
|
}
|
|
|
|
|
2017-01-28 15:52:34 +00:00
|
|
|
u64 __init e820__range_update(u64 start, u64 size, enum e820_type old_type, enum e820_type new_type)
|
2008-07-03 18:39:00 +00:00
|
|
|
{
|
x86/boot/e820: Create coherent API function names for E820 range operations
We have these three related functions:
extern void e820_add_region(u64 start, u64 size, int type);
extern u64 e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);
But it's not clear from the naming that they are 3 operations based around the
same 'memory range' concept. Rename them to better signal this, and move
the prototypes next to each other:
extern void e820__range_add (u64 start, u64 size, int type);
extern u64 e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);
Note that this improved organization of the functions shows another problem that was easy
to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
will be fixed in a separate patch.
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 13:19:36 +00:00
|
|
|
return __e820__range_update(e820_table, start, size, old_type, new_type);
|
2008-07-03 18:39:00 +00:00
|
|
|
}
|
|
|
|
|
2017-07-02 17:07:12 +00:00
|
|
|
static u64 __init e820__range_update_kexec(u64 start, u64 size, enum e820_type old_type, enum e820_type new_type)
|
2008-07-03 18:39:00 +00:00
|
|
|
{
|
2017-07-02 17:07:12 +00:00
|
|
|
return __e820__range_update(e820_table_kexec, start, size, old_type, new_type);
|
2008-07-03 18:39:00 +00:00
|
|
|
}
|
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/* Remove a range of memory from the E820 table: */
|
2017-01-28 21:34:55 +00:00
|
|
|
u64 __init e820__range_remove(u64 start, u64 size, enum e820_type old_type, bool check_type)
|
2008-06-21 21:48:05 +00:00
|
|
|
{
|
|
|
|
int i;
|
2010-01-22 03:21:04 +00:00
|
|
|
u64 end;
|
2008-06-21 21:48:05 +00:00
|
|
|
u64 real_removed_size = 0;
|
|
|
|
|
2008-06-24 21:58:38 +00:00
|
|
|
if (size > (ULLONG_MAX - start))
|
|
|
|
size = ULLONG_MAX - start;
|
|
|
|
|
2010-01-22 03:21:04 +00:00
|
|
|
end = start + size;
|
2017-01-31 17:53:34 +00:00
|
|
|
printk(KERN_DEBUG "e820: remove [mem %#010Lx-%#010Lx] ", start, end - 1);
|
2017-01-28 21:34:55 +00:00
|
|
|
if (check_type)
|
2010-03-30 05:38:29 +00:00
|
|
|
e820_print_type(old_type);
|
2017-01-28 11:27:45 +00:00
|
|
|
pr_cont("\n");
|
2010-01-22 03:21:04 +00:00
|
|
|
|
2017-01-27 13:06:21 +00:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
2017-01-28 11:16:17 +00:00
|
|
|
struct e820_entry *entry = &e820_table->entries[i];
|
2008-06-21 21:48:05 +00:00
|
|
|
u64 final_start, final_end;
|
2017-01-28 11:16:17 +00:00
|
|
|
u64 entry_end;
|
2008-06-21 21:48:05 +00:00
|
|
|
|
2017-01-28 21:34:55 +00:00
|
|
|
if (check_type && entry->type != old_type)
|
2008-06-21 21:48:05 +00:00
|
|
|
continue;
|
2010-03-30 05:38:29 +00:00
|
|
|
|
2017-01-28 11:16:17 +00:00
|
|
|
entry_end = entry->addr + entry->size;
|
2017-01-28 10:13:08 +00:00
|
|
|
|
|
|
|
/* Completely covered? */
|
2017-01-28 11:16:17 +00:00
|
|
|
if (entry->addr >= start && entry_end <= end) {
|
|
|
|
real_removed_size += entry->size;
|
2017-01-28 16:48:08 +00:00
|
|
|
memset(entry, 0, sizeof(*entry));
|
2008-06-21 21:48:05 +00:00
|
|
|
continue;
|
|
|
|
}
|
2010-03-30 05:38:29 +00:00
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/* Is the new range completely covered? */
|
2017-01-28 11:16:17 +00:00
|
|
|
if (entry->addr < start && entry_end > end) {
|
x86/boot/e820: Create coherent API function names for E820 range operations
We have these three related functions:
extern void e820_add_region(u64 start, u64 size, int type);
extern u64 e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);
But it's not clear from the naming that they are 3 operations based around the
same 'memory range' concept. Rename them to better signal this, and move
the prototypes next to each other:
extern void e820__range_add (u64 start, u64 size, int type);
extern u64 e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
extern u64 e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);
Note that this improved organization of the functions shows another problem that was easy
to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
will be fixed in a separate patch.
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 13:19:36 +00:00
|
|
|
e820__range_add(end, entry_end - end, entry->type);
|
2017-01-28 11:16:17 +00:00
|
|
|
entry->size = start - entry->addr;
|
2010-03-30 05:38:29 +00:00
|
|
|
real_removed_size += size;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/* Partially covered: */
|
2017-01-28 11:16:17 +00:00
|
|
|
final_start = max(start, entry->addr);
|
|
|
|
final_end = min(end, entry_end);
|
2008-06-21 21:48:05 +00:00
|
|
|
if (final_start >= final_end)
|
|
|
|
continue;
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2008-06-21 21:48:05 +00:00
|
|
|
real_removed_size += final_end - final_start;
|
|
|
|
|
2010-03-30 05:38:29 +00:00
|
|
|
/*
|
2017-01-28 10:13:08 +00:00
|
|
|
* Left range could be head or tail, so need to update
|
|
|
|
* the size first:
|
2010-03-30 05:38:29 +00:00
|
|
|
*/
|
2017-01-28 11:16:17 +00:00
|
|
|
entry->size -= final_end - final_start;
|
|
|
|
if (entry->addr < final_start)
|
2008-06-21 21:48:05 +00:00
|
|
|
continue;
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2017-01-28 11:16:17 +00:00
|
|
|
entry->addr = final_end;
|
2008-06-21 21:48:05 +00:00
|
|
|
}
|
|
|
|
return real_removed_size;
|
|
|
|
}
|
|
|
|
|
2017-01-28 13:03:04 +00:00
|
|
|
void __init e820__update_table_print(void)
|
2008-05-11 07:30:15 +00:00
|
|
|
{
|
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-28 17:00:35 +00:00
|
|
|
if (e820__update_table(e820_table))
|
2008-05-11 07:30:15 +00:00
|
|
|
return;
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2018-05-10 15:45:30 +00:00
|
|
|
pr_info("modified physical RAM map:\n");
|
2017-01-28 13:24:02 +00:00
|
|
|
e820__print_table("modified");
|
2008-05-11 07:30:15 +00:00
|
|
|
}
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2017-07-02 17:07:12 +00:00
|
|
|
static void __init e820__update_table_kexec(void)
|
2008-07-03 18:39:00 +00:00
|
|
|
{
|
2017-07-02 17:07:12 +00:00
|
|
|
e820__update_table(e820_table_kexec);
|
2008-07-03 18:39:00 +00:00
|
|
|
}
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2008-06-25 18:02:42 +00:00
|
|
|
#define MAX_GAP_END 0x100000000ull
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2008-05-11 07:30:15 +00:00
|
|
|
/*
|
2017-01-28 10:13:08 +00:00
|
|
|
* Search for a gap in the E820 memory space from 0 to MAX_GAP_END (4GB).
|
2008-05-11 07:30:15 +00:00
|
|
|
*/
|
2017-01-28 10:13:08 +00:00
|
|
|
static int __init e820_search_gap(unsigned long *gapstart, unsigned long *gapsize)
|
2008-05-11 07:30:15 +00:00
|
|
|
{
|
2016-12-25 14:35:51 +00:00
|
|
|
unsigned long long last = MAX_GAP_END;
|
2017-01-27 13:06:21 +00:00
|
|
|
int i = e820_table->nr_entries;
|
2008-05-11 07:30:15 +00:00
|
|
|
int found = 0;
|
|
|
|
|
|
|
|
while (--i >= 0) {
|
2017-01-27 13:06:21 +00:00
|
|
|
unsigned long long start = e820_table->entries[i].addr;
|
|
|
|
unsigned long long end = start + e820_table->entries[i].size;
|
2008-05-11 07:30:15 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Since "last" is at most 4GB, we know we'll
|
2017-01-28 10:13:08 +00:00
|
|
|
* fit in 32 bits if this condition is true:
|
2008-05-11 07:30:15 +00:00
|
|
|
*/
|
|
|
|
if (last > end) {
|
|
|
|
unsigned long gap = last - end;
|
|
|
|
|
2008-06-24 18:48:30 +00:00
|
|
|
if (gap >= *gapsize) {
|
|
|
|
*gapsize = gap;
|
|
|
|
*gapstart = end;
|
2008-05-11 07:30:15 +00:00
|
|
|
found = 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (start < last)
|
|
|
|
last = start;
|
|
|
|
}
|
2008-06-24 18:48:30 +00:00
|
|
|
return found;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2017-01-28 10:13:08 +00:00
|
|
|
* Search for the biggest gap in the low 32 bits of the E820
|
|
|
|
* memory space. We pass this space to the PCI subsystem, so
|
|
|
|
* that it can assign MMIO resources for hotplug or
|
|
|
|
* unconfigured devices in.
|
|
|
|
*
|
2008-06-24 18:48:30 +00:00
|
|
|
* Hopefully the BIOS let enough space left.
|
|
|
|
*/
|
2017-01-28 13:16:38 +00:00
|
|
|
__init void e820__setup_pci_gap(void)
|
2008-06-24 18:48:30 +00:00
|
|
|
{
|
2009-05-06 15:07:52 +00:00
|
|
|
unsigned long gapstart, gapsize;
|
2008-06-24 18:48:30 +00:00
|
|
|
int found;
|
|
|
|
|
|
|
|
gapsize = 0x400000;
|
2016-12-25 14:35:51 +00:00
|
|
|
found = e820_search_gap(&gapstart, &gapsize);
|
2008-05-11 07:30:15 +00:00
|
|
|
|
|
|
|
if (!found) {
|
2017-01-11 14:49:04 +00:00
|
|
|
#ifdef CONFIG_X86_64
|
2008-06-25 05:14:09 +00:00
|
|
|
gapstart = (max_pfn << PAGE_SHIFT) + 1024*1024;
|
2018-05-10 15:45:30 +00: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 14:49:04 +00:00
|
|
|
#else
|
|
|
|
gapstart = 0x10000000;
|
2008-05-11 07:30:15 +00:00
|
|
|
#endif
|
2017-01-11 14:49:04 +00:00
|
|
|
}
|
2008-05-11 07:30:15 +00:00
|
|
|
|
|
|
|
/*
|
2017-01-28 21:41:14 +00:00
|
|
|
* e820__reserve_resources_late() protects stolen RAM already:
|
2008-05-11 07:30:15 +00:00
|
|
|
*/
|
2009-05-06 15:07:52 +00:00
|
|
|
pci_mem_start = gapstart;
|
2008-05-11 07:30:15 +00:00
|
|
|
|
2018-05-10 15:45:30 +00:00
|
|
|
pr_info("[mem %#010lx-%#010lx] available for PCI devices\n",
|
|
|
|
gapstart, gapstart + gapsize - 1);
|
2008-05-11 07:30:15 +00:00
|
|
|
}
|
|
|
|
|
2016-09-17 21:39:26 +00:00
|
|
|
/*
|
|
|
|
* Called late during init, in free_initmem().
|
|
|
|
*
|
2017-07-02 17:07:12 +00:00
|
|
|
* Initial e820_table and e820_table_kexec are largish __initdata arrays.
|
2017-01-28 10:13:08 +00: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-17 21:39:26 +00:00
|
|
|
*/
|
2017-01-28 21:52:16 +00:00
|
|
|
__init void e820__reallocate_tables(void)
|
2016-09-17 21:39:26 +00:00
|
|
|
{
|
2017-01-27 12:54:38 +00:00
|
|
|
struct e820_table *n;
|
2016-09-17 21:39:26 +00:00
|
|
|
int size;
|
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
size = offsetof(struct e820_table, entries) + sizeof(struct e820_entry)*e820_table->nr_entries;
|
2019-01-12 07:16:24 +00:00
|
|
|
n = kmemdup(e820_table, size, GFP_KERNEL);
|
2016-09-17 21:39:26 +00:00
|
|
|
BUG_ON(!n);
|
2017-01-27 12:54:38 +00:00
|
|
|
e820_table = n;
|
2016-09-17 21:39:26 +00:00
|
|
|
|
2017-07-02 17:07:12 +00:00
|
|
|
size = offsetof(struct e820_table, entries) + sizeof(struct e820_entry)*e820_table_kexec->nr_entries;
|
2019-01-12 07:16:24 +00:00
|
|
|
n = kmemdup(e820_table_kexec, size, GFP_KERNEL);
|
2016-09-17 21:39:26 +00:00
|
|
|
BUG_ON(!n);
|
2017-07-02 17:07:12 +00:00
|
|
|
e820_table_kexec = n;
|
2017-07-02 17:07:32 +00:00
|
|
|
|
|
|
|
size = offsetof(struct e820_table, entries) + sizeof(struct e820_entry)*e820_table_firmware->nr_entries;
|
2019-01-12 07:16:24 +00:00
|
|
|
n = kmemdup(e820_table_firmware, size, GFP_KERNEL);
|
2017-07-02 17:07:32 +00:00
|
|
|
BUG_ON(!n);
|
|
|
|
e820_table_firmware = n;
|
2016-09-17 21:39:26 +00:00
|
|
|
}
|
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/*
|
|
|
|
* Because of the small fixed size of struct boot_params, only the first
|
|
|
|
* 128 E820 memory entries are passed to the kernel via boot_params.e820_table,
|
|
|
|
* the remaining (if any) entries are passed via the SETUP_E820_EXT node of
|
|
|
|
* struct setup_data, which is parsed here.
|
2008-06-11 03:33:39 +00:00
|
|
|
*/
|
2017-01-28 12:18:40 +00:00
|
|
|
void __init e820__memory_setup_extended(u64 phys_addr, u32 data_len)
|
2008-06-11 03:33:39 +00:00
|
|
|
{
|
|
|
|
int entries;
|
2017-01-29 11:56:13 +00:00
|
|
|
struct boot_e820_entry *extmap;
|
2013-08-13 21:46:41 +00:00
|
|
|
struct setup_data *sdata;
|
2008-06-11 03:33:39 +00:00
|
|
|
|
2013-08-13 21:46:41 +00:00
|
|
|
sdata = early_memremap(phys_addr, data_len);
|
2017-01-28 16:48:08 +00:00
|
|
|
entries = sdata->len / sizeof(*extmap);
|
2017-01-29 11:56:13 +00:00
|
|
|
extmap = (struct boot_e820_entry *)(sdata->data);
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2017-01-27 12:54:38 +00:00
|
|
|
__append_e820_table(extmap, entries);
|
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-28 17:00:35 +00:00
|
|
|
e820__update_table(e820_table);
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2017-07-02 17:07:12 +00:00
|
|
|
memcpy(e820_table_kexec, e820_table, sizeof(*e820_table_kexec));
|
2017-07-02 17:07:32 +00:00
|
|
|
memcpy(e820_table_firmware, e820_table, sizeof(*e820_table_firmware));
|
2017-07-02 17:06:28 +00:00
|
|
|
|
2015-02-24 09:13:28 +00:00
|
|
|
early_memunmap(sdata, data_len);
|
2018-05-10 15:45:30 +00:00
|
|
|
pr_info("extended physical RAM map:\n");
|
2017-01-28 13:24:02 +00:00
|
|
|
e820__print_table("extended");
|
2008-06-11 03:33:39 +00:00
|
|
|
}
|
|
|
|
|
2017-01-28 21:44:12 +00:00
|
|
|
/*
|
2008-05-21 03:10:58 +00:00
|
|
|
* Find the ranges of physical addresses that do not correspond to
|
2017-01-28 21:44:12 +00:00
|
|
|
* E820 RAM areas and register the corresponding pages as 'nosave' for
|
2017-01-28 10:13:08 +00:00
|
|
|
* hibernation (32-bit) or software suspend and suspend to RAM (64-bit).
|
2008-05-21 03:10:58 +00:00
|
|
|
*
|
2017-01-28 10:13:08 +00:00
|
|
|
* This function requires the E820 map to be sorted and without any
|
2014-09-12 03:03:58 +00:00
|
|
|
* overlapping entries.
|
2008-05-21 03:10:58 +00:00
|
|
|
*/
|
2017-01-28 21:44:12 +00:00
|
|
|
void __init e820__register_nosave_regions(unsigned long limit_pfn)
|
2008-05-21 03:10:58 +00:00
|
|
|
{
|
|
|
|
int i;
|
2014-09-12 03:03:58 +00:00
|
|
|
unsigned long pfn = 0;
|
2008-05-21 03:10:58 +00:00
|
|
|
|
2017-01-27 13:06:21 +00:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
2017-01-28 11:16:17 +00:00
|
|
|
struct e820_entry *entry = &e820_table->entries[i];
|
2008-05-21 03:10:58 +00:00
|
|
|
|
2017-01-28 11:16:17 +00:00
|
|
|
if (pfn < PFN_UP(entry->addr))
|
|
|
|
register_nosave_region(pfn, PFN_UP(entry->addr));
|
2008-05-21 03:10:58 +00:00
|
|
|
|
2017-01-28 11:16:17 +00:00
|
|
|
pfn = PFN_DOWN(entry->addr + entry->size);
|
2015-04-01 07:12:18 +00:00
|
|
|
|
2017-01-28 16:09:33 +00:00
|
|
|
if (entry->type != E820_TYPE_RAM && entry->type != E820_TYPE_RESERVED_KERN)
|
2017-01-28 11:16:17 +00:00
|
|
|
register_nosave_region(PFN_UP(entry->addr), pfn);
|
2008-05-21 03:10:58 +00:00
|
|
|
|
|
|
|
if (pfn >= limit_pfn)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2008-05-18 08:18:57 +00:00
|
|
|
|
2011-12-08 03:25:49 +00:00
|
|
|
#ifdef CONFIG_ACPI
|
2017-01-28 10:13:08 +00:00
|
|
|
/*
|
|
|
|
* Register ACPI NVS memory regions, so that we can save/restore them during
|
|
|
|
* hibernation and the subsequent resume:
|
2008-10-31 00:02:41 +00:00
|
|
|
*/
|
2017-01-28 21:44:12 +00:00
|
|
|
static int __init e820__register_nvs_regions(void)
|
2008-10-31 00:02:41 +00:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2017-01-27 13:06:21 +00:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
2017-01-28 11:16:17 +00:00
|
|
|
struct e820_entry *entry = &e820_table->entries[i];
|
2008-10-31 00:02:41 +00:00
|
|
|
|
2017-01-28 16:09:33 +00:00
|
|
|
if (entry->type == E820_TYPE_NVS)
|
2017-01-28 11:16:17 +00:00
|
|
|
acpi_nvs_register(entry->addr, entry->size);
|
2008-10-31 00:02:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2017-01-28 21:44:12 +00:00
|
|
|
core_initcall(e820__register_nvs_regions);
|
2008-10-31 00:02:41 +00:00
|
|
|
#endif
|
|
|
|
|
2008-06-01 20:17:38 +00:00
|
|
|
/*
|
2021-03-18 14:28:01 +00:00
|
|
|
* Allocate the requested number of bytes with the requested alignment
|
2017-01-28 12:46:28 +00:00
|
|
|
* and return (the physical address) to the caller. Also register this
|
2017-07-02 17:07:12 +00:00
|
|
|
* range in the 'kexec' E820 table as a reserved range.
|
2017-01-28 12:46:28 +00:00
|
|
|
*
|
|
|
|
* This allows kexec to fake a new mptable, as if it came from the real
|
|
|
|
* system.
|
2008-06-01 20:17:38 +00:00
|
|
|
*/
|
2017-01-28 12:46:28 +00:00
|
|
|
u64 __init e820__memblock_alloc_reserved(u64 size, u64 align)
|
2008-06-01 20:17:38 +00:00
|
|
|
{
|
|
|
|
u64 addr;
|
|
|
|
|
2019-03-12 06:29:31 +00:00
|
|
|
addr = memblock_phys_alloc(size, align);
|
2011-07-12 09:15:58 +00:00
|
|
|
if (addr) {
|
2017-07-02 17:07:12 +00:00
|
|
|
e820__range_update_kexec(addr, size, E820_TYPE_RAM, E820_TYPE_RESERVED);
|
2018-05-10 15:45:30 +00:00
|
|
|
pr_info("update e820_table_kexec for e820__memblock_alloc_reserved()\n");
|
2017-07-02 17:07:12 +00:00
|
|
|
e820__update_table_kexec();
|
2009-05-06 12:02:19 +00:00
|
|
|
}
|
2008-06-01 20:17:38 +00:00
|
|
|
|
|
|
|
return addr;
|
|
|
|
}
|
|
|
|
|
2008-06-04 02:34:00 +00:00
|
|
|
#ifdef CONFIG_X86_32
|
|
|
|
# ifdef CONFIG_X86_PAE
|
|
|
|
# define MAX_ARCH_PFN (1ULL<<(36-PAGE_SHIFT))
|
|
|
|
# else
|
|
|
|
# define MAX_ARCH_PFN (1ULL<<(32-PAGE_SHIFT))
|
|
|
|
# endif
|
|
|
|
#else /* CONFIG_X86_32 */
|
2008-06-04 20:21:29 +00:00
|
|
|
# define MAX_ARCH_PFN MAXMEM>>PAGE_SHIFT
|
2008-06-04 02:34:00 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Find the highest page frame number we have available
|
|
|
|
*/
|
2017-01-28 15:52:34 +00:00
|
|
|
static unsigned long __init e820_end_pfn(unsigned long limit_pfn, enum e820_type type)
|
2008-06-04 02:34:00 +00:00
|
|
|
{
|
2008-07-09 01:56:38 +00:00
|
|
|
int i;
|
|
|
|
unsigned long last_pfn = 0;
|
2008-06-04 02:34:00 +00:00
|
|
|
unsigned long max_arch_pfn = MAX_ARCH_PFN;
|
|
|
|
|
2017-01-27 13:06:21 +00:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
2017-01-28 11:16:17 +00:00
|
|
|
struct e820_entry *entry = &e820_table->entries[i];
|
2008-07-11 03:38:26 +00:00
|
|
|
unsigned long start_pfn;
|
2008-07-09 01:56:38 +00:00
|
|
|
unsigned long end_pfn;
|
|
|
|
|
2017-01-28 11:16:17 +00:00
|
|
|
if (entry->type != type)
|
2008-07-09 10:01:14 +00:00
|
|
|
continue;
|
|
|
|
|
2017-01-28 11:16:17 +00:00
|
|
|
start_pfn = entry->addr >> PAGE_SHIFT;
|
|
|
|
end_pfn = (entry->addr + entry->size) >> PAGE_SHIFT;
|
2008-07-11 03:38:26 +00:00
|
|
|
|
|
|
|
if (start_pfn >= limit_pfn)
|
|
|
|
continue;
|
|
|
|
if (end_pfn > limit_pfn) {
|
|
|
|
last_pfn = limit_pfn;
|
|
|
|
break;
|
|
|
|
}
|
2008-07-09 01:56:38 +00:00
|
|
|
if (end_pfn > last_pfn)
|
|
|
|
last_pfn = end_pfn;
|
|
|
|
}
|
2008-06-04 02:34:00 +00:00
|
|
|
|
|
|
|
if (last_pfn > max_arch_pfn)
|
|
|
|
last_pfn = max_arch_pfn;
|
|
|
|
|
2018-05-10 15:45:30 +00:00
|
|
|
pr_info("last_pfn = %#lx max_arch_pfn = %#lx\n",
|
|
|
|
last_pfn, max_arch_pfn);
|
2008-06-04 02:34:00 +00:00
|
|
|
return last_pfn;
|
|
|
|
}
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2017-01-28 21:52:16 +00:00
|
|
|
unsigned long __init e820__end_of_ram_pfn(void)
|
2008-07-11 03:38:26 +00:00
|
|
|
{
|
2017-01-28 16:09:33 +00:00
|
|
|
return e820_end_pfn(MAX_ARCH_PFN, E820_TYPE_RAM);
|
2008-07-11 03:38:26 +00:00
|
|
|
}
|
2008-06-04 02:34:00 +00:00
|
|
|
|
2017-01-28 21:52:16 +00:00
|
|
|
unsigned long __init e820__end_of_low_ram_pfn(void)
|
2008-07-11 03:38:26 +00:00
|
|
|
{
|
2017-01-28 16:09:33 +00:00
|
|
|
return e820_end_pfn(1UL << (32 - PAGE_SHIFT), E820_TYPE_RAM);
|
2008-07-11 03:38:26 +00:00
|
|
|
}
|
2008-06-04 02:34:00 +00:00
|
|
|
|
2016-09-17 21:39:25 +00:00
|
|
|
static void __init early_panic(char *msg)
|
2008-06-10 19:55:54 +00:00
|
|
|
{
|
|
|
|
early_printk(msg);
|
|
|
|
panic(msg);
|
|
|
|
}
|
|
|
|
|
2008-07-10 11:17:00 +00:00
|
|
|
static int userdef __initdata;
|
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/* The "mem=nopentium" boot option disables 4MB page tables on 32-bit kernels: */
|
2008-06-10 19:55:54 +00:00
|
|
|
static int __init parse_memopt(char *p)
|
|
|
|
{
|
|
|
|
u64 mem_size;
|
|
|
|
|
|
|
|
if (!p)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (!strcmp(p, "nopentium")) {
|
2011-02-04 01:38:05 +00:00
|
|
|
#ifdef CONFIG_X86_32
|
2008-06-10 19:55:54 +00:00
|
|
|
setup_clear_cpu_cap(X86_FEATURE_PSE);
|
|
|
|
return 0;
|
2011-02-04 01:38:05 +00:00
|
|
|
#else
|
2017-01-28 11:27:45 +00:00
|
|
|
pr_warn("mem=nopentium ignored! (only supported on x86_32)\n");
|
2011-02-04 01:38:05 +00:00
|
|
|
return -EINVAL;
|
2008-06-10 19:55:54 +00:00
|
|
|
#endif
|
2011-02-04 01:38:05 +00:00
|
|
|
}
|
2008-06-10 19:55:54 +00:00
|
|
|
|
2008-07-10 11:17:00 +00:00
|
|
|
userdef = 1;
|
2008-06-10 19:55:54 +00:00
|
|
|
mem_size = memparse(p, &p);
|
2017-01-28 10:13:08 +00:00
|
|
|
|
|
|
|
/* Don't remove all memory when getting "mem={invalid}" parameter: */
|
2011-02-04 01:38:04 +00:00
|
|
|
if (mem_size == 0)
|
|
|
|
return -EINVAL;
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2017-01-28 16:09:33 +00:00
|
|
|
e820__range_remove(mem_size, ULLONG_MAX - mem_size, E820_TYPE_RAM, 1);
|
2008-06-25 19:39:16 +00:00
|
|
|
|
2019-02-14 10:42:39 +00:00
|
|
|
#ifdef CONFIG_MEMORY_HOTPLUG
|
|
|
|
max_mem_size = mem_size;
|
|
|
|
#endif
|
|
|
|
|
2008-06-10 19:55:54 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
early_param("mem", parse_memopt);
|
|
|
|
|
2012-11-17 03:39:23 +00:00
|
|
|
static int __init parse_memmap_one(char *p)
|
2008-06-10 19:55:54 +00:00
|
|
|
{
|
|
|
|
char *oldp;
|
|
|
|
u64 start_at, mem_size;
|
|
|
|
|
2008-07-05 11:53:39 +00:00
|
|
|
if (!p)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2008-09-09 13:56:08 +00:00
|
|
|
if (!strncmp(p, "exactmap", 8)) {
|
2017-01-27 13:06:21 +00:00
|
|
|
e820_table->nr_entries = 0;
|
2008-06-10 19:55:54 +00:00
|
|
|
userdef = 1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
oldp = p;
|
|
|
|
mem_size = memparse(p, &p);
|
|
|
|
if (p == oldp)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
userdef = 1;
|
|
|
|
if (*p == '@') {
|
|
|
|
start_at = memparse(p+1, &p);
|
2017-01-28 16:09:33 +00:00
|
|
|
e820__range_add(start_at, mem_size, E820_TYPE_RAM);
|
2008-06-10 19:55:54 +00:00
|
|
|
} else if (*p == '#') {
|
|
|
|
start_at = memparse(p+1, &p);
|
2017-01-28 16:09:33 +00:00
|
|
|
e820__range_add(start_at, mem_size, E820_TYPE_ACPI);
|
2008-06-10 19:55:54 +00:00
|
|
|
} else if (*p == '$') {
|
|
|
|
start_at = memparse(p+1, &p);
|
2017-01-28 16:09:33 +00:00
|
|
|
e820__range_add(start_at, mem_size, E820_TYPE_RESERVED);
|
2015-04-01 07:12:18 +00:00
|
|
|
} else if (*p == '!') {
|
|
|
|
start_at = memparse(p+1, &p);
|
2017-01-28 16:09:33 +00:00
|
|
|
e820__range_add(start_at, mem_size, E820_TYPE_PRAM);
|
2018-02-02 23:10:20 +00: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 10:13:08 +00:00
|
|
|
} else {
|
2017-01-28 16:09:33 +00:00
|
|
|
e820__range_remove(mem_size, ULLONG_MAX - mem_size, E820_TYPE_RAM, 1);
|
2017-01-28 10:13:08 +00:00
|
|
|
}
|
2008-07-13 05:57:07 +00:00
|
|
|
|
2008-06-10 19:55:54 +00:00
|
|
|
return *p == '\0' ? 0 : -EINVAL;
|
|
|
|
}
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2012-11-17 03:39:23 +00:00
|
|
|
static int __init parse_memmap_opt(char *str)
|
|
|
|
{
|
|
|
|
while (str) {
|
|
|
|
char *k = strchr(str, ',');
|
|
|
|
|
|
|
|
if (k)
|
|
|
|
*k++ = 0;
|
|
|
|
|
|
|
|
parse_memmap_one(str);
|
|
|
|
str = k;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2008-06-10 19:55:54 +00:00
|
|
|
early_param("memmap", parse_memmap_opt);
|
|
|
|
|
2017-01-28 21:27:28 +00: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 12:25:45 +00:00
|
|
|
{
|
2022-02-24 02:07:35 +00:00
|
|
|
struct setup_indirect *indirect;
|
2017-01-28 12:25:45 +00:00
|
|
|
struct setup_data *data;
|
2022-02-24 02:07:35 +00:00
|
|
|
u64 pa_data, pa_next;
|
|
|
|
u32 len;
|
2017-01-28 12:25:45 +00:00
|
|
|
|
|
|
|
pa_data = boot_params.hdr.setup_data;
|
|
|
|
if (!pa_data)
|
|
|
|
return;
|
|
|
|
|
|
|
|
while (pa_data) {
|
|
|
|
data = early_memremap(pa_data, sizeof(*data));
|
2022-02-24 02:07:35 +00:00
|
|
|
if (!data) {
|
|
|
|
pr_warn("e820: failed to memremap setup_data entry\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
len = sizeof(*data);
|
|
|
|
pa_next = data->next;
|
|
|
|
|
2017-01-28 16:09:33 +00:00
|
|
|
e820__range_update(pa_data, sizeof(*data)+data->len, E820_TYPE_RAM, E820_TYPE_RESERVED_KERN);
|
x86/kexec: Do not reserve EFI setup_data in the kexec e820 table
The e820 table for the kexec kernel unconditionally marks setup_data as
reserved because the second kernel can reuse setup_data passed by the
1st kernel's boot loader, for example SETUP_PCI marked regions like PCI
BIOS, etc.
SETUP_EFI types, however, are used by kexec itself to enable EFI in the
2nd kernel. Thus, it is pointless to add this type of setup_data to the
kexec e820 table as reserved.
IOW, what happens is this:
- 1st physical boot: no SETUP_EFI.
- kexec loads a new kernel and prepares a SETUP_EFI setup_data blob, then
reboots the machine.
- 2nd kernel sees SETUP_EFI, reserves it both in the e820 and in the
kexec e820 table.
- If another kexec load is executed, it prepares a new SETUP_EFI blob and
then reboots the machine into the new kernel.
5. The 3rd kexec-ed kernel has two SETUP_EFI ranges reserved. And so on...
Thus skip SETUP_EFI while reserving setup_data in the e820_table_kexec
table because it is not needed.
[ bp: Heavily massage commit message, shorten line and improve comment. ]
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20200212110424.GA2938@dhcp-128-65.nay.redhat.com
2020-02-12 11:04:24 +00:00
|
|
|
|
|
|
|
/*
|
2022-06-30 08:36:12 +00:00
|
|
|
* SETUP_EFI and SETUP_IMA are supplied by kexec and do not need
|
|
|
|
* to be reserved.
|
x86/kexec: Do not reserve EFI setup_data in the kexec e820 table
The e820 table for the kexec kernel unconditionally marks setup_data as
reserved because the second kernel can reuse setup_data passed by the
1st kernel's boot loader, for example SETUP_PCI marked regions like PCI
BIOS, etc.
SETUP_EFI types, however, are used by kexec itself to enable EFI in the
2nd kernel. Thus, it is pointless to add this type of setup_data to the
kexec e820 table as reserved.
IOW, what happens is this:
- 1st physical boot: no SETUP_EFI.
- kexec loads a new kernel and prepares a SETUP_EFI setup_data blob, then
reboots the machine.
- 2nd kernel sees SETUP_EFI, reserves it both in the e820 and in the
kexec e820 table.
- If another kexec load is executed, it prepares a new SETUP_EFI blob and
then reboots the machine into the new kernel.
5. The 3rd kexec-ed kernel has two SETUP_EFI ranges reserved. And so on...
Thus skip SETUP_EFI while reserving setup_data in the e820_table_kexec
table because it is not needed.
[ bp: Heavily massage commit message, shorten line and improve comment. ]
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20200212110424.GA2938@dhcp-128-65.nay.redhat.com
2020-02-12 11:04:24 +00:00
|
|
|
*/
|
2022-06-30 08:36:12 +00:00
|
|
|
if (data->type != SETUP_EFI && data->type != SETUP_IMA)
|
x86/kexec: Do not reserve EFI setup_data in the kexec e820 table
The e820 table for the kexec kernel unconditionally marks setup_data as
reserved because the second kernel can reuse setup_data passed by the
1st kernel's boot loader, for example SETUP_PCI marked regions like PCI
BIOS, etc.
SETUP_EFI types, however, are used by kexec itself to enable EFI in the
2nd kernel. Thus, it is pointless to add this type of setup_data to the
kexec e820 table as reserved.
IOW, what happens is this:
- 1st physical boot: no SETUP_EFI.
- kexec loads a new kernel and prepares a SETUP_EFI setup_data blob, then
reboots the machine.
- 2nd kernel sees SETUP_EFI, reserves it both in the e820 and in the
kexec e820 table.
- If another kexec load is executed, it prepares a new SETUP_EFI blob and
then reboots the machine into the new kernel.
5. The 3rd kexec-ed kernel has two SETUP_EFI ranges reserved. And so on...
Thus skip SETUP_EFI while reserving setup_data in the e820_table_kexec
table because it is not needed.
[ bp: Heavily massage commit message, shorten line and improve comment. ]
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20200212110424.GA2938@dhcp-128-65.nay.redhat.com
2020-02-12 11:04:24 +00:00
|
|
|
e820__range_update_kexec(pa_data,
|
|
|
|
sizeof(*data) + data->len,
|
|
|
|
E820_TYPE_RAM, E820_TYPE_RESERVED_KERN);
|
2019-11-12 13:46:40 +00:00
|
|
|
|
2022-02-24 02:07:35 +00:00
|
|
|
if (data->type == SETUP_INDIRECT) {
|
|
|
|
len += data->len;
|
|
|
|
early_memunmap(data, sizeof(*data));
|
|
|
|
data = early_memremap(pa_data, len);
|
|
|
|
if (!data) {
|
|
|
|
pr_warn("e820: failed to memremap indirect setup_data\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
indirect = (struct setup_indirect *)data->data;
|
|
|
|
|
|
|
|
if (indirect->type != SETUP_INDIRECT) {
|
|
|
|
e820__range_update(indirect->addr, indirect->len,
|
|
|
|
E820_TYPE_RAM, E820_TYPE_RESERVED_KERN);
|
|
|
|
e820__range_update_kexec(indirect->addr, indirect->len,
|
|
|
|
E820_TYPE_RAM, E820_TYPE_RESERVED_KERN);
|
|
|
|
}
|
2019-11-12 13:46:40 +00:00
|
|
|
}
|
|
|
|
|
2022-02-24 02:07:35 +00:00
|
|
|
pa_data = pa_next;
|
|
|
|
early_memunmap(data, len);
|
2017-01-28 12:25:45 +00: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-28 17:00:35 +00:00
|
|
|
e820__update_table(e820_table);
|
2017-07-02 17:07:12 +00:00
|
|
|
e820__update_table(e820_table_kexec);
|
2017-01-28 21:27:28 +00:00
|
|
|
|
|
|
|
pr_info("extended physical RAM map:\n");
|
2017-01-28 13:24:02 +00:00
|
|
|
e820__print_table("reserve setup_data");
|
2017-01-28 12:25:45 +00:00
|
|
|
}
|
|
|
|
|
2017-01-28 12:37:17 +00:00
|
|
|
/*
|
|
|
|
* Called after parse_early_param(), after early parameters (such as mem=)
|
|
|
|
* have been processed, in which case we already have an E820 table filled in
|
|
|
|
* via the parameter callback function(s), but it's not sorted and printed yet:
|
|
|
|
*/
|
|
|
|
void __init e820__finish_early_params(void)
|
2008-06-10 19:55:54 +00:00
|
|
|
{
|
|
|
|
if (userdef) {
|
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-28 17:00:35 +00:00
|
|
|
if (e820__update_table(e820_table) < 0)
|
2008-06-10 19:55:54 +00:00
|
|
|
early_panic("Invalid user supplied memory map");
|
|
|
|
|
2018-05-10 15:45:30 +00:00
|
|
|
pr_info("user-defined physical RAM map:\n");
|
2017-01-28 13:24:02 +00:00
|
|
|
e820__print_table("user");
|
2008-06-10 19:55:54 +00:00
|
|
|
}
|
|
|
|
}
|
2008-06-16 20:03:31 +00:00
|
|
|
|
2017-01-28 13:33:48 +00:00
|
|
|
static const char *__init e820_type_to_string(struct e820_entry *entry)
|
2008-06-27 11:12:55 +00:00
|
|
|
{
|
2017-01-28 13:33:48 +00:00
|
|
|
switch (entry->type) {
|
2017-01-28 16:09:33 +00: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 08:40:26 +00:00
|
|
|
case E820_TYPE_RESERVED: return "Reserved";
|
2019-11-07 01:43:16 +00:00
|
|
|
case E820_TYPE_SOFT_RESERVED: return "Soft Reserved";
|
2017-01-29 08:40:26 +00:00
|
|
|
default: return "Unknown E820 type";
|
2008-06-27 11:12:55 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-01-28 13:33:48 +00:00
|
|
|
static unsigned long __init e820_type_to_iomem_type(struct e820_entry *entry)
|
2016-01-26 20:57:20 +00:00
|
|
|
{
|
2017-01-28 13:33:48 +00:00
|
|
|
switch (entry->type) {
|
2017-01-28 16:09:33 +00: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 08:40:26 +00:00
|
|
|
case E820_TYPE_RESERVED: /* Fall-through: */
|
2019-11-07 01:43:16 +00:00
|
|
|
case E820_TYPE_SOFT_RESERVED: /* Fall-through: */
|
2017-01-28 16:09:33 +00:00
|
|
|
default: return IORESOURCE_MEM;
|
2016-01-26 20:57:20 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-01-28 13:33:48 +00:00
|
|
|
static unsigned long __init e820_type_to_iores_desc(struct e820_entry *entry)
|
2016-01-26 20:57:20 +00:00
|
|
|
{
|
2017-01-28 13:33:48 +00:00
|
|
|
switch (entry->type) {
|
2017-01-28 16:09:33 +00: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;
|
2019-04-23 01:30:05 +00:00
|
|
|
case E820_TYPE_RESERVED: return IORES_DESC_RESERVED;
|
2019-11-07 01:43:16 +00:00
|
|
|
case E820_TYPE_SOFT_RESERVED: return IORES_DESC_SOFT_RESERVED;
|
2017-01-28 16:09:33 +00:00
|
|
|
case E820_TYPE_RESERVED_KERN: /* Fall-through: */
|
|
|
|
case E820_TYPE_RAM: /* Fall-through: */
|
|
|
|
case E820_TYPE_UNUSABLE: /* Fall-through: */
|
|
|
|
default: return IORES_DESC_NONE;
|
2016-01-26 20:57:20 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-01-29 08:40:26 +00:00
|
|
|
static bool __init do_mark_busy(enum e820_type type, struct resource *res)
|
2015-04-03 16:05:28 +00:00
|
|
|
{
|
|
|
|
/* this is the legacy bios/dos rom-shadow + mmio region */
|
|
|
|
if (res->start < (1ULL<<20))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
/*
|
2019-11-07 01:43:16 +00:00
|
|
|
* Treat persistent memory and other special memory ranges like
|
|
|
|
* device memory, i.e. reserve it for exclusive use of a driver
|
2015-04-03 16:05:28 +00:00
|
|
|
*/
|
|
|
|
switch (type) {
|
2017-01-28 16:09:33 +00:00
|
|
|
case E820_TYPE_RESERVED:
|
2019-11-07 01:43:16 +00:00
|
|
|
case E820_TYPE_SOFT_RESERVED:
|
2017-01-28 16:09:33 +00:00
|
|
|
case E820_TYPE_PRAM:
|
|
|
|
case E820_TYPE_PMEM:
|
2015-04-03 16:05:28 +00:00
|
|
|
return false;
|
2017-01-29 08:40:26 +00:00
|
|
|
case E820_TYPE_RESERVED_KERN:
|
|
|
|
case E820_TYPE_RAM:
|
|
|
|
case E820_TYPE_ACPI:
|
|
|
|
case E820_TYPE_NVS:
|
|
|
|
case E820_TYPE_UNUSABLE:
|
2015-04-03 16:05:28 +00:00
|
|
|
default:
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-06-16 20:03:31 +00:00
|
|
|
/*
|
2017-01-28 10:13:08 +00:00
|
|
|
* Mark E820 reserved areas as busy for the resource manager:
|
2008-06-16 20:03:31 +00:00
|
|
|
*/
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2008-08-29 06:09:23 +00:00
|
|
|
static struct resource __initdata *e820_res;
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2017-01-28 21:41:14 +00:00
|
|
|
void __init e820__reserve_resources(void)
|
2008-06-16 20:03:31 +00:00
|
|
|
{
|
|
|
|
int i;
|
2008-08-28 20:52:25 +00:00
|
|
|
struct resource *res;
|
2008-08-29 06:09:23 +00:00
|
|
|
u64 end;
|
2008-06-16 20:03:31 +00:00
|
|
|
|
memblock: stop using implicit alignment to SMP_CACHE_BYTES
When a memblock allocation APIs are called with align = 0, the alignment
is implicitly set to SMP_CACHE_BYTES.
Implicit alignment is done deep in the memblock allocator and it can
come as a surprise. Not that such an alignment would be wrong even
when used incorrectly but it is better to be explicit for the sake of
clarity and the prinicple of the least surprise.
Replace all such uses of memblock APIs with the 'align' parameter
explicitly set to SMP_CACHE_BYTES and stop implicit alignment assignment
in the memblock internal allocation functions.
For the case when memblock APIs are used via helper functions, e.g. like
iommu_arena_new_node() in Alpha, the helper functions were detected with
Coccinelle's help and then manually examined and updated where
appropriate.
The direct memblock APIs users were updated using the semantic patch below:
@@
expression size, min_addr, max_addr, nid;
@@
(
|
- memblock_alloc_try_nid_raw(size, 0, min_addr, max_addr, nid)
+ memblock_alloc_try_nid_raw(size, SMP_CACHE_BYTES, min_addr, max_addr,
nid)
|
- memblock_alloc_try_nid_nopanic(size, 0, min_addr, max_addr, nid)
+ memblock_alloc_try_nid_nopanic(size, SMP_CACHE_BYTES, min_addr, max_addr,
nid)
|
- memblock_alloc_try_nid(size, 0, min_addr, max_addr, nid)
+ memblock_alloc_try_nid(size, SMP_CACHE_BYTES, min_addr, max_addr, nid)
|
- memblock_alloc(size, 0)
+ memblock_alloc(size, SMP_CACHE_BYTES)
|
- memblock_alloc_raw(size, 0)
+ memblock_alloc_raw(size, SMP_CACHE_BYTES)
|
- memblock_alloc_from(size, 0, min_addr)
+ memblock_alloc_from(size, SMP_CACHE_BYTES, min_addr)
|
- memblock_alloc_nopanic(size, 0)
+ memblock_alloc_nopanic(size, SMP_CACHE_BYTES)
|
- memblock_alloc_low(size, 0)
+ memblock_alloc_low(size, SMP_CACHE_BYTES)
|
- memblock_alloc_low_nopanic(size, 0)
+ memblock_alloc_low_nopanic(size, SMP_CACHE_BYTES)
|
- memblock_alloc_from_nopanic(size, 0, min_addr)
+ memblock_alloc_from_nopanic(size, SMP_CACHE_BYTES, min_addr)
|
- memblock_alloc_node(size, 0, nid)
+ memblock_alloc_node(size, SMP_CACHE_BYTES, nid)
)
[mhocko@suse.com: changelog update]
[akpm@linux-foundation.org: coding-style fixes]
[rppt@linux.ibm.com: fix missed uses of implicit alignment]
Link: http://lkml.kernel.org/r/20181016133656.GA10925@rapoport-lnx
Link: http://lkml.kernel.org/r/1538687224-17535-1-git-send-email-rppt@linux.vnet.ibm.com
Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
Suggested-by: Michal Hocko <mhocko@suse.com>
Acked-by: Paul Burton <paul.burton@mips.com> [MIPS]
Acked-by: Michael Ellerman <mpe@ellerman.id.au> [powerpc]
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Chris Zankel <chris@zankel.net>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Guan Xuetao <gxt@pku.edu.cn>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Richard Weinberger <richard@nod.at>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-10-30 22:09:57 +00:00
|
|
|
res = memblock_alloc(sizeof(*res) * e820_table->nr_entries,
|
|
|
|
SMP_CACHE_BYTES);
|
2019-03-12 06:30:31 +00:00
|
|
|
if (!res)
|
|
|
|
panic("%s: Failed to allocate %zu bytes\n", __func__,
|
|
|
|
sizeof(*res) * e820_table->nr_entries);
|
2008-08-28 20:52:25 +00:00
|
|
|
e820_res = res;
|
2017-01-28 13:33:48 +00:00
|
|
|
|
2017-01-27 13:06:21 +00:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
2017-01-28 13:33:48 +00:00
|
|
|
struct e820_entry *entry = e820_table->entries + i;
|
|
|
|
|
|
|
|
end = entry->addr + entry->size - 1;
|
2008-09-11 08:31:50 +00:00
|
|
|
if (end != (resource_size_t)end) {
|
2008-06-16 20:03:31 +00:00
|
|
|
res++;
|
|
|
|
continue;
|
|
|
|
}
|
2017-01-28 13:33:48 +00:00
|
|
|
res->start = entry->addr;
|
|
|
|
res->end = end;
|
|
|
|
res->name = e820_type_to_string(entry);
|
|
|
|
res->flags = e820_type_to_iomem_type(entry);
|
|
|
|
res->desc = e820_type_to_iores_desc(entry);
|
2008-08-29 06:09:23 +00:00
|
|
|
|
|
|
|
/*
|
2017-01-28 21:41:14 +00: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 06:09:23 +00:00
|
|
|
*/
|
2017-01-28 13:33:48 +00:00
|
|
|
if (do_mark_busy(entry->type, res)) {
|
x86: Clean up late e820 resource allocation
This makes the late e820 resources use 'insert_resource_expand_to_fit()'
instead of doing a 'reserve_region_with_split()', and also avoids
marking them as IORESOURCE_BUSY.
This results in us being perfectly happy to use pre-existing PCI
resources even if they were marked as being in a reserved region, while
still avoiding any _new_ allocations in the reserved regions. It also
makes for a simpler and more accurate resource tree.
Example resource allocation from Jonathan Corbet, who has firmware that
has an e820 reserved entry that covered a big range (e0000000-fed003ff),
and that had various PCI resources in it set up by firmware.
With old kernels, the reserved range would force us to re-allocate all
pre-existing PCI resources, and his reserved range would end up looking
like this:
e0000000-fed003ff : reserved
fec00000-fec00fff : IOAPIC 0
fed00000-fed003ff : HPET 0
where only the pre-allocated special regions (IOAPIC and HPET) were kept
around.
With 2.6.28-rc2, which uses 'reserve_region_with_split()', Jonathan's
resource tree looked like this:
e0000000-fe7fffff : reserved
fe800000-fe8fffff : PCI Bus 0000:01
fe800000-fe8fffff : reserved
fe900000-fe9d9aff : reserved
fe9d9b00-fe9d9bff : 0000:00:1f.3
fe9d9b00-fe9d9bff : reserved
fe9d9c00-fe9d9fff : 0000:00:1a.7
fe9d9c00-fe9d9fff : reserved
fe9da000-fe9dafff : 0000:00:03.3
fe9da000-fe9dafff : reserved
fe9db000-fe9dbfff : 0000:00:19.0
fe9db000-fe9dbfff : reserved
fe9dc000-fe9dffff : 0000:00:1b.0
fe9dc000-fe9dffff : reserved
fe9e0000-fe9fffff : 0000:00:19.0
fe9e0000-fe9fffff : reserved
fea00000-fea7ffff : 0000:00:02.0
fea00000-fea7ffff : reserved
fea80000-feafffff : 0000:00:02.1
fea80000-feafffff : reserved
feb00000-febfffff : 0000:00:02.0
feb00000-febfffff : reserved
fec00000-fed003ff : reserved
fec00000-fec00fff : IOAPIC 0
fed00000-fed003ff : HPET 0
and because the reserved entry had been split and moved into the
individual resources, and because it used the IORESOURCE_BUSY flag, the
drivers that actually wanted to _use_ those resources couldn't actually
attach to them:
e1000e 0000:00:19.0: BAR 0: can't reserve mem region [0xfe9e0000-0xfe9fffff]
HDA Intel 0000:00:1b.0: BAR 0: can't reserve mem region [0xfe9dc000-0xfe9dffff]
with this patch, the resource tree instead becomes
e0000000-fed003ff : reserved
fe800000-fe8fffff : PCI Bus 0000:01
fe9d9b00-fe9d9bff : 0000:00:1f.3
fe9d9c00-fe9d9fff : 0000:00:1a.7
fe9d9c00-fe9d9fff : ehci_hcd
fe9da000-fe9dafff : 0000:00:03.3
fe9db000-fe9dbfff : 0000:00:19.0
fe9db000-fe9dbfff : e1000e
fe9dc000-fe9dffff : 0000:00:1b.0
fe9dc000-fe9dffff : ICH HD audio
fe9e0000-fe9fffff : 0000:00:19.0
fe9e0000-fe9fffff : e1000e
fea00000-fea7ffff : 0000:00:02.0
fea80000-feafffff : 0000:00:02.1
feb00000-febfffff : 0000:00:02.0
fec00000-fec00fff : IOAPIC 0
fed00000-fed003ff : HPET 0
ie the one reserved region now ends up surrounding all the PCI resources
that were allocated inside of it by firmware, and because it is not
marked BUSY, drivers have no problem attaching to the pre-allocated
resources.
Reported-and-tested-by: Jonathan Corbet <corbet@lwn.net>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Robert Hancock <hancockr@shaw.ca>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-11-01 17:17:22 +00:00
|
|
|
res->flags |= IORESOURCE_BUSY;
|
2008-08-28 20:52:25 +00:00
|
|
|
insert_resource(&iomem_resource, res);
|
x86: Clean up late e820 resource allocation
This makes the late e820 resources use 'insert_resource_expand_to_fit()'
instead of doing a 'reserve_region_with_split()', and also avoids
marking them as IORESOURCE_BUSY.
This results in us being perfectly happy to use pre-existing PCI
resources even if they were marked as being in a reserved region, while
still avoiding any _new_ allocations in the reserved regions. It also
makes for a simpler and more accurate resource tree.
Example resource allocation from Jonathan Corbet, who has firmware that
has an e820 reserved entry that covered a big range (e0000000-fed003ff),
and that had various PCI resources in it set up by firmware.
With old kernels, the reserved range would force us to re-allocate all
pre-existing PCI resources, and his reserved range would end up looking
like this:
e0000000-fed003ff : reserved
fec00000-fec00fff : IOAPIC 0
fed00000-fed003ff : HPET 0
where only the pre-allocated special regions (IOAPIC and HPET) were kept
around.
With 2.6.28-rc2, which uses 'reserve_region_with_split()', Jonathan's
resource tree looked like this:
e0000000-fe7fffff : reserved
fe800000-fe8fffff : PCI Bus 0000:01
fe800000-fe8fffff : reserved
fe900000-fe9d9aff : reserved
fe9d9b00-fe9d9bff : 0000:00:1f.3
fe9d9b00-fe9d9bff : reserved
fe9d9c00-fe9d9fff : 0000:00:1a.7
fe9d9c00-fe9d9fff : reserved
fe9da000-fe9dafff : 0000:00:03.3
fe9da000-fe9dafff : reserved
fe9db000-fe9dbfff : 0000:00:19.0
fe9db000-fe9dbfff : reserved
fe9dc000-fe9dffff : 0000:00:1b.0
fe9dc000-fe9dffff : reserved
fe9e0000-fe9fffff : 0000:00:19.0
fe9e0000-fe9fffff : reserved
fea00000-fea7ffff : 0000:00:02.0
fea00000-fea7ffff : reserved
fea80000-feafffff : 0000:00:02.1
fea80000-feafffff : reserved
feb00000-febfffff : 0000:00:02.0
feb00000-febfffff : reserved
fec00000-fed003ff : reserved
fec00000-fec00fff : IOAPIC 0
fed00000-fed003ff : HPET 0
and because the reserved entry had been split and moved into the
individual resources, and because it used the IORESOURCE_BUSY flag, the
drivers that actually wanted to _use_ those resources couldn't actually
attach to them:
e1000e 0000:00:19.0: BAR 0: can't reserve mem region [0xfe9e0000-0xfe9fffff]
HDA Intel 0000:00:1b.0: BAR 0: can't reserve mem region [0xfe9dc000-0xfe9dffff]
with this patch, the resource tree instead becomes
e0000000-fed003ff : reserved
fe800000-fe8fffff : PCI Bus 0000:01
fe9d9b00-fe9d9bff : 0000:00:1f.3
fe9d9c00-fe9d9fff : 0000:00:1a.7
fe9d9c00-fe9d9fff : ehci_hcd
fe9da000-fe9dafff : 0000:00:03.3
fe9db000-fe9dbfff : 0000:00:19.0
fe9db000-fe9dbfff : e1000e
fe9dc000-fe9dffff : 0000:00:1b.0
fe9dc000-fe9dffff : ICH HD audio
fe9e0000-fe9fffff : 0000:00:19.0
fe9e0000-fe9fffff : e1000e
fea00000-fea7ffff : 0000:00:02.0
fea80000-feafffff : 0000:00:02.1
feb00000-febfffff : 0000:00:02.0
fec00000-fec00fff : IOAPIC 0
fed00000-fed003ff : HPET 0
ie the one reserved region now ends up surrounding all the PCI resources
that were allocated inside of it by firmware, and because it is not
marked BUSY, drivers have no problem attaching to the pre-allocated
resources.
Reported-and-tested-by: Jonathan Corbet <corbet@lwn.net>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Robert Hancock <hancockr@shaw.ca>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-11-01 17:17:22 +00:00
|
|
|
}
|
2008-06-16 20:03:31 +00:00
|
|
|
res++;
|
|
|
|
}
|
2008-06-27 11:12:55 +00:00
|
|
|
|
2017-07-02 17:07:32 +00: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 10:13:08 +00:00
|
|
|
|
2017-01-28 13:33:48 +00:00
|
|
|
firmware_map_add_early(entry->addr, entry->addr + entry->size, e820_type_to_string(entry));
|
2008-06-27 11:12:55 +00:00
|
|
|
}
|
2008-06-16 20:03:31 +00:00
|
|
|
}
|
|
|
|
|
2017-01-28 21:41:14 +00:00
|
|
|
/*
|
|
|
|
* How much should we pad the end of RAM, depending on where it is?
|
|
|
|
*/
|
2016-09-17 21:39:25 +00:00
|
|
|
static unsigned long __init ram_alignment(resource_size_t pos)
|
2009-05-06 15:06:44 +00:00
|
|
|
{
|
|
|
|
unsigned long mb = pos >> 20;
|
|
|
|
|
|
|
|
/* To 64kB in the first megabyte */
|
|
|
|
if (!mb)
|
|
|
|
return 64*1024;
|
|
|
|
|
|
|
|
/* To 1MB in the first 16MB */
|
|
|
|
if (mb < 16)
|
|
|
|
return 1024*1024;
|
|
|
|
|
2009-10-11 21:17:16 +00:00
|
|
|
/* To 64MB for anything above that */
|
|
|
|
return 64*1024*1024;
|
2009-05-06 15:06:44 +00:00
|
|
|
}
|
|
|
|
|
2009-07-01 19:32:18 +00:00
|
|
|
#define MAX_RESOURCE_SIZE ((resource_size_t)-1)
|
|
|
|
|
2017-01-28 21:41:14 +00:00
|
|
|
void __init e820__reserve_resources_late(void)
|
2008-08-28 20:52:25 +00:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
struct resource *res;
|
|
|
|
|
|
|
|
res = e820_res;
|
2017-01-27 13:06:21 +00:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
2008-08-29 06:09:23 +00:00
|
|
|
if (!res->parent && res->end)
|
x86: Clean up late e820 resource allocation
This makes the late e820 resources use 'insert_resource_expand_to_fit()'
instead of doing a 'reserve_region_with_split()', and also avoids
marking them as IORESOURCE_BUSY.
This results in us being perfectly happy to use pre-existing PCI
resources even if they were marked as being in a reserved region, while
still avoiding any _new_ allocations in the reserved regions. It also
makes for a simpler and more accurate resource tree.
Example resource allocation from Jonathan Corbet, who has firmware that
has an e820 reserved entry that covered a big range (e0000000-fed003ff),
and that had various PCI resources in it set up by firmware.
With old kernels, the reserved range would force us to re-allocate all
pre-existing PCI resources, and his reserved range would end up looking
like this:
e0000000-fed003ff : reserved
fec00000-fec00fff : IOAPIC 0
fed00000-fed003ff : HPET 0
where only the pre-allocated special regions (IOAPIC and HPET) were kept
around.
With 2.6.28-rc2, which uses 'reserve_region_with_split()', Jonathan's
resource tree looked like this:
e0000000-fe7fffff : reserved
fe800000-fe8fffff : PCI Bus 0000:01
fe800000-fe8fffff : reserved
fe900000-fe9d9aff : reserved
fe9d9b00-fe9d9bff : 0000:00:1f.3
fe9d9b00-fe9d9bff : reserved
fe9d9c00-fe9d9fff : 0000:00:1a.7
fe9d9c00-fe9d9fff : reserved
fe9da000-fe9dafff : 0000:00:03.3
fe9da000-fe9dafff : reserved
fe9db000-fe9dbfff : 0000:00:19.0
fe9db000-fe9dbfff : reserved
fe9dc000-fe9dffff : 0000:00:1b.0
fe9dc000-fe9dffff : reserved
fe9e0000-fe9fffff : 0000:00:19.0
fe9e0000-fe9fffff : reserved
fea00000-fea7ffff : 0000:00:02.0
fea00000-fea7ffff : reserved
fea80000-feafffff : 0000:00:02.1
fea80000-feafffff : reserved
feb00000-febfffff : 0000:00:02.0
feb00000-febfffff : reserved
fec00000-fed003ff : reserved
fec00000-fec00fff : IOAPIC 0
fed00000-fed003ff : HPET 0
and because the reserved entry had been split and moved into the
individual resources, and because it used the IORESOURCE_BUSY flag, the
drivers that actually wanted to _use_ those resources couldn't actually
attach to them:
e1000e 0000:00:19.0: BAR 0: can't reserve mem region [0xfe9e0000-0xfe9fffff]
HDA Intel 0000:00:1b.0: BAR 0: can't reserve mem region [0xfe9dc000-0xfe9dffff]
with this patch, the resource tree instead becomes
e0000000-fed003ff : reserved
fe800000-fe8fffff : PCI Bus 0000:01
fe9d9b00-fe9d9bff : 0000:00:1f.3
fe9d9c00-fe9d9fff : 0000:00:1a.7
fe9d9c00-fe9d9fff : ehci_hcd
fe9da000-fe9dafff : 0000:00:03.3
fe9db000-fe9dbfff : 0000:00:19.0
fe9db000-fe9dbfff : e1000e
fe9dc000-fe9dffff : 0000:00:1b.0
fe9dc000-fe9dffff : ICH HD audio
fe9e0000-fe9fffff : 0000:00:19.0
fe9e0000-fe9fffff : e1000e
fea00000-fea7ffff : 0000:00:02.0
fea80000-feafffff : 0000:00:02.1
feb00000-febfffff : 0000:00:02.0
fec00000-fec00fff : IOAPIC 0
fed00000-fed003ff : HPET 0
ie the one reserved region now ends up surrounding all the PCI resources
that were allocated inside of it by firmware, and because it is not
marked BUSY, drivers have no problem attaching to the pre-allocated
resources.
Reported-and-tested-by: Jonathan Corbet <corbet@lwn.net>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Robert Hancock <hancockr@shaw.ca>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-11-01 17:17:22 +00:00
|
|
|
insert_resource_expand_to_fit(&iomem_resource, res);
|
2008-08-28 20:52:25 +00:00
|
|
|
res++;
|
|
|
|
}
|
2009-05-06 15:06:44 +00:00
|
|
|
|
|
|
|
/*
|
2017-01-28 10:13:08 +00:00
|
|
|
* Try to bump up RAM regions to reasonable boundaries, to
|
2009-05-06 15:06:44 +00:00
|
|
|
* avoid stolen RAM:
|
|
|
|
*/
|
2017-01-27 13:06:21 +00:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
|
|
|
struct e820_entry *entry = &e820_table->entries[i];
|
2009-07-01 19:32:18 +00:00
|
|
|
u64 start, end;
|
2009-05-06 15:06:44 +00:00
|
|
|
|
2017-01-28 16:09:33 +00:00
|
|
|
if (entry->type != E820_TYPE_RAM)
|
2009-05-06 15:06:44 +00:00
|
|
|
continue;
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2009-05-06 15:06:44 +00:00
|
|
|
start = entry->addr + entry->size;
|
2009-07-01 19:32:18 +00:00
|
|
|
end = round_up(start, ram_alignment(start)) - 1;
|
|
|
|
if (end > MAX_RESOURCE_SIZE)
|
|
|
|
end = MAX_RESOURCE_SIZE;
|
|
|
|
if (start >= end)
|
2009-05-06 15:06:44 +00:00
|
|
|
continue;
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2017-01-31 17:53:34 +00:00
|
|
|
printk(KERN_DEBUG "e820: reserve RAM buffer [mem %#010llx-%#010llx]\n", start, end);
|
2017-01-28 10:13:08 +00:00
|
|
|
reserve_region_with_split(&iomem_resource, start, end, "RAM buffer");
|
2009-05-06 15:06:44 +00:00
|
|
|
}
|
2008-08-28 20:52:25 +00:00
|
|
|
}
|
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/*
|
|
|
|
* Pass the firmware (bootloader) E820 map to the kernel and process it:
|
|
|
|
*/
|
2017-01-28 08:58:49 +00:00
|
|
|
char *__init e820__memory_setup_default(void)
|
2008-06-17 02:58:28 +00:00
|
|
|
{
|
|
|
|
char *who = "BIOS-e820";
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2008-06-17 02:58:28 +00:00
|
|
|
/*
|
|
|
|
* Try to copy the BIOS-supplied E820-map.
|
|
|
|
*
|
|
|
|
* Otherwise fake a memory map; one section from 0k->640k,
|
|
|
|
* the next section from 1mb->appropriate_mem_k
|
|
|
|
*/
|
2017-01-28 10:13:08 +00:00
|
|
|
if (append_e820_table(boot_params.e820_table, boot_params.e820_entries) < 0) {
|
2008-06-19 00:27:08 +00:00
|
|
|
u64 mem_size;
|
2008-06-17 02:58:28 +00:00
|
|
|
|
2017-01-28 10:13:08 +00:00
|
|
|
/* Compare results from other methods and take the one that gives more RAM: */
|
|
|
|
if (boot_params.alt_mem_k < boot_params.screen_info.ext_mem_k) {
|
2008-06-17 02:58:28 +00:00
|
|
|
mem_size = boot_params.screen_info.ext_mem_k;
|
|
|
|
who = "BIOS-88";
|
|
|
|
} else {
|
|
|
|
mem_size = boot_params.alt_mem_k;
|
|
|
|
who = "BIOS-e801";
|
|
|
|
}
|
|
|
|
|
2017-01-27 13:06:21 +00:00
|
|
|
e820_table->nr_entries = 0;
|
2017-01-28 16:09:33 +00:00
|
|
|
e820__range_add(0, LOWMEMSIZE(), E820_TYPE_RAM);
|
|
|
|
e820__range_add(HIGH_MEMORY, mem_size << 10, E820_TYPE_RAM);
|
2008-06-17 02:58:28 +00:00
|
|
|
}
|
|
|
|
|
2017-01-29 11:56:13 +00:00
|
|
|
/* We just appended a lot of ranges, sanitize the table: */
|
|
|
|
e820__update_table(e820_table);
|
|
|
|
|
2008-06-17 02:58:28 +00:00
|
|
|
return who;
|
|
|
|
}
|
|
|
|
|
2017-01-28 08:58:49 +00:00
|
|
|
/*
|
|
|
|
* Calls e820__memory_setup_default() in essence to pick up the firmware/bootloader
|
|
|
|
* E820 map - with an optional platform quirk available for virtual platforms
|
|
|
|
* to override this method of boot environment processing:
|
|
|
|
*/
|
|
|
|
void __init e820__memory_setup(void)
|
2008-06-17 02:58:28 +00:00
|
|
|
{
|
2008-07-03 18:35:37 +00:00
|
|
|
char *who;
|
|
|
|
|
2017-01-28 16:01:06 +00:00
|
|
|
/* This is a firmware interface ABI - make sure we don't break it: */
|
2017-01-29 11:56:13 +00:00
|
|
|
BUILD_BUG_ON(sizeof(struct boot_e820_entry) != 20);
|
2017-01-28 16:01:06 +00:00
|
|
|
|
2009-08-20 08:19:54 +00:00
|
|
|
who = x86_init.resources.memory_setup();
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2017-07-02 17:07:12 +00:00
|
|
|
memcpy(e820_table_kexec, e820_table, sizeof(*e820_table_kexec));
|
2017-07-02 17:07:32 +00:00
|
|
|
memcpy(e820_table_firmware, e820_table, sizeof(*e820_table_firmware));
|
2017-01-28 10:13:08 +00:00
|
|
|
|
2018-05-10 15:45:30 +00:00
|
|
|
pr_info("BIOS-provided physical RAM map:\n");
|
2017-01-28 13:24:02 +00:00
|
|
|
e820__print_table(who);
|
2008-06-17 02:58:28 +00:00
|
|
|
}
|
2010-08-25 20:39:17 +00:00
|
|
|
|
x86/boot/e820: Rename memblock_x86_fill() to e820__memblock_setup() and improve the explanations
So memblock_x86_fill() is another E820 code misnomer:
- nothing in its name tells us that it's part of the E820 subsystem ...
- The 'fill' wording is ambiguous and doesn't tell us whether it's a single
entry or some process - while the _real_ purpose of the function is hidden,
which is to do a complete setup of the (platform independent) memblock regions.
So rename it accordingly, to e820__memblock_setup().
Also translate this incomprehensible and misleading comment:
/*
* EFI may have more than 128 entries
* We are safe to enable resizing, beause memblock_x86_fill()
* is rather later for x86
*/
memblock_allow_resize();
The worst aspect of this comment isn't even the sloppy typos, but that it
casually mentions a '128' number with no explanation, which makes one lead
to the assumption that this is related to the well-known limit of a maximum
of 128 E820 entries passed via legacy bootloaders.
But no, the _real_ meaning of 128 here is that of the memblock subsystem,
which too happens to have a 128 entries limit for very early memblock
regions (which is unrelated to E820), via INIT_MEMBLOCK_REGIONS ...
So change the comment to a more comprehensible version:
/*
* The bootstrap memblock region count maximum is 128 entries
* (INIT_MEMBLOCK_REGIONS), but EFI might pass us more E820 entries
* than that - so allow memblock resizing.
*
* This is safe, because this call happens pretty late during x86 setup,
* so we know about reserved memory regions already. (This is important
* so that memblock resizing does no stomp over reserved areas.)
*/
memblock_allow_resize();
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 10:37:42 +00:00
|
|
|
void __init e820__memblock_setup(void)
|
2010-08-25 20:39:17 +00:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
u64 end;
|
|
|
|
|
|
|
|
/*
|
x86/boot/e820: Rename memblock_x86_fill() to e820__memblock_setup() and improve the explanations
So memblock_x86_fill() is another E820 code misnomer:
- nothing in its name tells us that it's part of the E820 subsystem ...
- The 'fill' wording is ambiguous and doesn't tell us whether it's a single
entry or some process - while the _real_ purpose of the function is hidden,
which is to do a complete setup of the (platform independent) memblock regions.
So rename it accordingly, to e820__memblock_setup().
Also translate this incomprehensible and misleading comment:
/*
* EFI may have more than 128 entries
* We are safe to enable resizing, beause memblock_x86_fill()
* is rather later for x86
*/
memblock_allow_resize();
The worst aspect of this comment isn't even the sloppy typos, but that it
casually mentions a '128' number with no explanation, which makes one lead
to the assumption that this is related to the well-known limit of a maximum
of 128 E820 entries passed via legacy bootloaders.
But no, the _real_ meaning of 128 here is that of the memblock subsystem,
which too happens to have a 128 entries limit for very early memblock
regions (which is unrelated to E820), via INIT_MEMBLOCK_REGIONS ...
So change the comment to a more comprehensible version:
/*
* The bootstrap memblock region count maximum is 128 entries
* (INIT_MEMBLOCK_REGIONS), but EFI might pass us more E820 entries
* than that - so allow memblock resizing.
*
* This is safe, because this call happens pretty late during x86 setup,
* so we know about reserved memory regions already. (This is important
* so that memblock resizing does no stomp over reserved areas.)
*/
memblock_allow_resize();
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 10:37:42 +00:00
|
|
|
* The bootstrap memblock region count maximum is 128 entries
|
|
|
|
* (INIT_MEMBLOCK_REGIONS), but EFI might pass us more E820 entries
|
|
|
|
* than that - so allow memblock resizing.
|
|
|
|
*
|
|
|
|
* This is safe, because this call happens pretty late during x86 setup,
|
|
|
|
* so we know about reserved memory regions already. (This is important
|
|
|
|
* so that memblock resizing does no stomp over reserved areas.)
|
2010-08-25 20:39:17 +00:00
|
|
|
*/
|
2011-12-08 18:22:08 +00:00
|
|
|
memblock_allow_resize();
|
2010-08-25 20:39:17 +00:00
|
|
|
|
2017-01-27 13:06:21 +00:00
|
|
|
for (i = 0; i < e820_table->nr_entries; i++) {
|
2017-01-28 11:16:17 +00:00
|
|
|
struct e820_entry *entry = &e820_table->entries[i];
|
2010-08-25 20:39:17 +00:00
|
|
|
|
2017-01-28 11:16:17 +00:00
|
|
|
end = entry->addr + entry->size;
|
2010-08-25 20:39:17 +00:00
|
|
|
if (end != (resource_size_t)end)
|
|
|
|
continue;
|
|
|
|
|
2019-11-07 01:43:16 +00:00
|
|
|
if (entry->type == E820_TYPE_SOFT_RESERVED)
|
|
|
|
memblock_reserve(entry->addr, entry->size);
|
|
|
|
|
2017-01-28 16:09:33 +00:00
|
|
|
if (entry->type != E820_TYPE_RAM && entry->type != E820_TYPE_RESERVED_KERN)
|
2018-10-26 22:10:24 +00:00
|
|
|
continue;
|
|
|
|
|
|
|
|
memblock_add(entry->addr, entry->size);
|
2010-08-25 20:39:17 +00:00
|
|
|
}
|
|
|
|
|
x86/boot/e820: Rename memblock_x86_fill() to e820__memblock_setup() and improve the explanations
So memblock_x86_fill() is another E820 code misnomer:
- nothing in its name tells us that it's part of the E820 subsystem ...
- The 'fill' wording is ambiguous and doesn't tell us whether it's a single
entry or some process - while the _real_ purpose of the function is hidden,
which is to do a complete setup of the (platform independent) memblock regions.
So rename it accordingly, to e820__memblock_setup().
Also translate this incomprehensible and misleading comment:
/*
* EFI may have more than 128 entries
* We are safe to enable resizing, beause memblock_x86_fill()
* is rather later for x86
*/
memblock_allow_resize();
The worst aspect of this comment isn't even the sloppy typos, but that it
casually mentions a '128' number with no explanation, which makes one lead
to the assumption that this is related to the well-known limit of a maximum
of 128 E820 entries passed via legacy bootloaders.
But no, the _real_ meaning of 128 here is that of the memblock subsystem,
which too happens to have a 128 entries limit for very early memblock
regions (which is unrelated to E820), via INIT_MEMBLOCK_REGIONS ...
So change the comment to a more comprehensible version:
/*
* The bootstrap memblock region count maximum is 128 entries
* (INIT_MEMBLOCK_REGIONS), but EFI might pass us more E820 entries
* than that - so allow memblock resizing.
*
* This is safe, because this call happens pretty late during x86 setup,
* so we know about reserved memory regions already. (This is important
* so that memblock resizing does no stomp over reserved areas.)
*/
memblock_allow_resize();
No change in functionality.
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-28 10:37:42 +00:00
|
|
|
/* Throw away partial pages: */
|
2012-10-22 23:35:18 +00:00
|
|
|
memblock_trim_memory(PAGE_SIZE);
|
|
|
|
|
2010-08-25 20:39:17 +00:00
|
|
|
memblock_dump_all();
|
|
|
|
}
|