xref: /openbmc/linux/arch/x86/include/asm/e820/types.h (revision 262b45ae)
1 /* SPDX-License-Identifier: GPL-2.0 */
2 #ifndef _ASM_E820_TYPES_H
3 #define _ASM_E820_TYPES_H
4 
5 #include <uapi/asm/bootparam.h>
6 
7 /*
8  * These are the E820 types known to the kernel:
9  */
10 enum e820_type {
11 	E820_TYPE_RAM		= 1,
12 	E820_TYPE_RESERVED	= 2,
13 	E820_TYPE_ACPI		= 3,
14 	E820_TYPE_NVS		= 4,
15 	E820_TYPE_UNUSABLE	= 5,
16 	E820_TYPE_PMEM		= 7,
17 
18 	/*
19 	 * This is a non-standardized way to represent ADR or
20 	 * NVDIMM regions that persist over a reboot.
21 	 *
22 	 * The kernel will ignore their special capabilities
23 	 * unless the CONFIG_X86_PMEM_LEGACY=y option is set.
24 	 *
25 	 * ( Note that older platforms also used 6 for the same
26 	 *   type of memory, but newer versions switched to 12 as
27 	 *   6 was assigned differently. Some time they will learn... )
28 	 */
29 	E820_TYPE_PRAM		= 12,
30 
31 	/*
32 	 * Special-purpose memory is indicated to the system via the
33 	 * EFI_MEMORY_SP attribute. Define an e820 translation of this
34 	 * memory type for the purpose of reserving this range and
35 	 * marking it with the IORES_DESC_SOFT_RESERVED designation.
36 	 */
37 	E820_TYPE_SOFT_RESERVED	= 0xefffffff,
38 
39 	/*
40 	 * Reserved RAM used by the kernel itself if
41 	 * CONFIG_INTEL_TXT=y is enabled, memory of this type
42 	 * will be included in the S3 integrity calculation
43 	 * and so should not include any memory that the BIOS
44 	 * might alter over the S3 transition:
45 	 */
46 	E820_TYPE_RESERVED_KERN	= 128,
47 };
48 
49 /*
50  * A single E820 map entry, describing a memory range of [addr...addr+size-1],
51  * of 'type' memory type:
52  *
53  * (We pack it because there can be thousands of them on large systems.)
54  */
55 struct e820_entry {
56 	u64			addr;
57 	u64			size;
58 	enum e820_type		type;
59 } __attribute__((packed));
60 
61 /*
62  * The legacy E820 BIOS limits us to 128 (E820_MAX_ENTRIES_ZEROPAGE) nodes
63  * due to the constrained space in the zeropage.
64  *
65  * On large systems we can easily have thousands of nodes with RAM,
66  * which cannot be fit into so few entries - so we have a mechanism
67  * to extend the e820 table size at build-time, via the E820_MAX_ENTRIES
68  * define below.
69  *
70  * ( Those extra entries are enumerated via the EFI memory map, not
71  *   via the legacy zeropage mechanism. )
72  *
73  * Size our internal memory map tables to have room for these additional
74  * entries, based on a heuristic calculation: up to three entries per
75  * NUMA node, plus E820_MAX_ENTRIES_ZEROPAGE for some extra space.
76  *
77  * This allows for bootstrap/firmware quirks such as possible duplicate
78  * E820 entries that might need room in the same arrays, prior to the
79  * call to e820__update_table() to remove duplicates.  The allowance
80  * of three memory map entries per node is "enough" entries for
81  * the initial hardware platform motivating this mechanism to make
82  * use of additional EFI map entries.  Future platforms may want
83  * to allow more than three entries per node or otherwise refine
84  * this size.
85  */
86 
87 #include <linux/numa.h>
88 
89 #define E820_MAX_ENTRIES	(E820_MAX_ENTRIES_ZEROPAGE + 3*MAX_NUMNODES)
90 
91 /*
92  * The whole array of E820 entries:
93  */
94 struct e820_table {
95 	__u32 nr_entries;
96 	struct e820_entry entries[E820_MAX_ENTRIES];
97 };
98 
99 /*
100  * Various well-known legacy memory ranges in physical memory:
101  */
102 #define ISA_START_ADDRESS	0x000a0000
103 #define ISA_END_ADDRESS		0x00100000
104 
105 #define BIOS_BEGIN		0x000a0000
106 #define BIOS_END		0x00100000
107 
108 #define HIGH_MEMORY		0x00100000
109 
110 #define BIOS_ROM_BASE		0xffe00000
111 #define BIOS_ROM_END		0xffffffff
112 
113 #endif /* _ASM_E820_TYPES_H */
114