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 | |