diff options
Diffstat (limited to 'Documentation/x86/x86_64')
-rw-r--r-- | Documentation/x86/x86_64/00-INDEX | 16 | ||||
-rw-r--r-- | Documentation/x86/x86_64/boot-options.txt | 314 | ||||
-rw-r--r-- | Documentation/x86/x86_64/cpu-hotplug-spec | 21 | ||||
-rw-r--r-- | Documentation/x86/x86_64/fake-numa-for-cpusets | 66 | ||||
-rw-r--r-- | Documentation/x86/x86_64/kernel-stacks | 99 | ||||
-rw-r--r-- | Documentation/x86/x86_64/machinecheck | 77 | ||||
-rw-r--r-- | Documentation/x86/x86_64/mm.txt | 28 | ||||
-rw-r--r-- | Documentation/x86/x86_64/uefi.txt | 42 |
8 files changed, 663 insertions, 0 deletions
diff --git a/Documentation/x86/x86_64/00-INDEX b/Documentation/x86/x86_64/00-INDEX new file mode 100644 index 000000000000..92fc20ab5f0e --- /dev/null +++ b/Documentation/x86/x86_64/00-INDEX | |||
@@ -0,0 +1,16 @@ | |||
1 | 00-INDEX | ||
2 | - This file | ||
3 | boot-options.txt | ||
4 | - AMD64-specific boot options. | ||
5 | cpu-hotplug-spec | ||
6 | - Firmware support for CPU hotplug under Linux/x86-64 | ||
7 | fake-numa-for-cpusets | ||
8 | - Using numa=fake and CPUSets for Resource Management | ||
9 | kernel-stacks | ||
10 | - Context-specific per-processor interrupt stacks. | ||
11 | machinecheck | ||
12 | - Configurable sysfs parameters for the x86-64 machine check code. | ||
13 | mm.txt | ||
14 | - Memory layout of x86-64 (4 level page tables, 46 bits physical). | ||
15 | uefi.txt | ||
16 | - Booting Linux via Unified Extensible Firmware Interface. | ||
diff --git a/Documentation/x86/x86_64/boot-options.txt b/Documentation/x86/x86_64/boot-options.txt new file mode 100644 index 000000000000..b0c7b6c4abda --- /dev/null +++ b/Documentation/x86/x86_64/boot-options.txt | |||
@@ -0,0 +1,314 @@ | |||
1 | AMD64 specific boot options | ||
2 | |||
3 | There are many others (usually documented in driver documentation), but | ||
4 | only the AMD64 specific ones are listed here. | ||
5 | |||
6 | Machine check | ||
7 | |||
8 | mce=off disable machine check | ||
9 | mce=bootlog Enable logging of machine checks left over from booting. | ||
10 | Disabled by default on AMD because some BIOS leave bogus ones. | ||
11 | If your BIOS doesn't do that it's a good idea to enable though | ||
12 | to make sure you log even machine check events that result | ||
13 | in a reboot. On Intel systems it is enabled by default. | ||
14 | mce=nobootlog | ||
15 | Disable boot machine check logging. | ||
16 | mce=tolerancelevel (number) | ||
17 | 0: always panic on uncorrected errors, log corrected errors | ||
18 | 1: panic or SIGBUS on uncorrected errors, log corrected errors | ||
19 | 2: SIGBUS or log uncorrected errors, log corrected errors | ||
20 | 3: never panic or SIGBUS, log all errors (for testing only) | ||
21 | Default is 1 | ||
22 | Can be also set using sysfs which is preferable. | ||
23 | |||
24 | nomce (for compatibility with i386): same as mce=off | ||
25 | |||
26 | Everything else is in sysfs now. | ||
27 | |||
28 | APICs | ||
29 | |||
30 | apic Use IO-APIC. Default | ||
31 | |||
32 | noapic Don't use the IO-APIC. | ||
33 | |||
34 | disableapic Don't use the local APIC | ||
35 | |||
36 | nolapic Don't use the local APIC (alias for i386 compatibility) | ||
37 | |||
38 | pirq=... See Documentation/i386/IO-APIC.txt | ||
39 | |||
40 | noapictimer Don't set up the APIC timer | ||
41 | |||
42 | no_timer_check Don't check the IO-APIC timer. This can work around | ||
43 | problems with incorrect timer initialization on some boards. | ||
44 | |||
45 | apicmaintimer Run time keeping from the local APIC timer instead | ||
46 | of using the PIT/HPET interrupt for this. This is useful | ||
47 | when the PIT/HPET interrupts are unreliable. | ||
48 | |||
49 | noapicmaintimer Don't do time keeping using the APIC timer. | ||
50 | Useful when this option was auto selected, but doesn't work. | ||
51 | |||
52 | apicpmtimer | ||
53 | Do APIC timer calibration using the pmtimer. Implies | ||
54 | apicmaintimer. Useful when your PIT timer is totally | ||
55 | broken. | ||
56 | |||
57 | disable_8254_timer / enable_8254_timer | ||
58 | Enable interrupt 0 timer routing over the 8254 in addition to over | ||
59 | the IO-APIC. The kernel tries to set a sensible default. | ||
60 | |||
61 | Early Console | ||
62 | |||
63 | syntax: earlyprintk=vga | ||
64 | earlyprintk=serial[,ttySn[,baudrate]] | ||
65 | |||
66 | The early console is useful when the kernel crashes before the | ||
67 | normal console is initialized. It is not enabled by | ||
68 | default because it has some cosmetic problems. | ||
69 | Append ,keep to not disable it when the real console takes over. | ||
70 | Only vga or serial at a time, not both. | ||
71 | Currently only ttyS0 and ttyS1 are supported. | ||
72 | Interaction with the standard serial driver is not very good. | ||
73 | The VGA output is eventually overwritten by the real console. | ||
74 | |||
75 | Timing | ||
76 | |||
77 | notsc | ||
78 | Don't use the CPU time stamp counter to read the wall time. | ||
79 | This can be used to work around timing problems on multiprocessor systems | ||
80 | with not properly synchronized CPUs. | ||
81 | |||
82 | report_lost_ticks | ||
83 | Report when timer interrupts are lost because some code turned off | ||
84 | interrupts for too long. | ||
85 | |||
86 | nmi_watchdog=NUMBER[,panic] | ||
87 | NUMBER can be: | ||
88 | 0 don't use an NMI watchdog | ||
89 | 1 use the IO-APIC timer for the NMI watchdog | ||
90 | 2 use the local APIC for the NMI watchdog using a performance counter. Note | ||
91 | This will use one performance counter and the local APIC's performance | ||
92 | vector. | ||
93 | When panic is specified panic when an NMI watchdog timeout occurs. | ||
94 | This is useful when you use a panic=... timeout and need the box | ||
95 | quickly up again. | ||
96 | |||
97 | nohpet | ||
98 | Don't use the HPET timer. | ||
99 | |||
100 | Idle loop | ||
101 | |||
102 | idle=poll | ||
103 | Don't do power saving in the idle loop using HLT, but poll for rescheduling | ||
104 | event. This will make the CPUs eat a lot more power, but may be useful | ||
105 | to get slightly better performance in multiprocessor benchmarks. It also | ||
106 | makes some profiling using performance counters more accurate. | ||
107 | Please note that on systems with MONITOR/MWAIT support (like Intel EM64T | ||
108 | CPUs) this option has no performance advantage over the normal idle loop. | ||
109 | It may also interact badly with hyperthreading. | ||
110 | |||
111 | Rebooting | ||
112 | |||
113 | reboot=b[ios] | t[riple] | k[bd] | a[cpi] | e[fi] [, [w]arm | [c]old] | ||
114 | bios Use the CPU reboot vector for warm reset | ||
115 | warm Don't set the cold reboot flag | ||
116 | cold Set the cold reboot flag | ||
117 | triple Force a triple fault (init) | ||
118 | kbd Use the keyboard controller. cold reset (default) | ||
119 | acpi Use the ACPI RESET_REG in the FADT. If ACPI is not configured or the | ||
120 | ACPI reset does not work, the reboot path attempts the reset using | ||
121 | the keyboard controller. | ||
122 | efi Use efi reset_system runtime service. If EFI is not configured or the | ||
123 | EFI reset does not work, the reboot path attempts the reset using | ||
124 | the keyboard controller. | ||
125 | |||
126 | Using warm reset will be much faster especially on big memory | ||
127 | systems because the BIOS will not go through the memory check. | ||
128 | Disadvantage is that not all hardware will be completely reinitialized | ||
129 | on reboot so there may be boot problems on some systems. | ||
130 | |||
131 | reboot=force | ||
132 | |||
133 | Don't stop other CPUs on reboot. This can make reboot more reliable | ||
134 | in some cases. | ||
135 | |||
136 | Non Executable Mappings | ||
137 | |||
138 | noexec=on|off | ||
139 | |||
140 | on Enable(default) | ||
141 | off Disable | ||
142 | |||
143 | SMP | ||
144 | |||
145 | additional_cpus=NUM Allow NUM more CPUs for hotplug | ||
146 | (defaults are specified by the BIOS, see Documentation/x86_64/cpu-hotplug-spec) | ||
147 | |||
148 | NUMA | ||
149 | |||
150 | numa=off Only set up a single NUMA node spanning all memory. | ||
151 | |||
152 | numa=noacpi Don't parse the SRAT table for NUMA setup | ||
153 | |||
154 | numa=fake=CMDLINE | ||
155 | If a number, fakes CMDLINE nodes and ignores NUMA setup of the | ||
156 | actual machine. Otherwise, system memory is configured | ||
157 | depending on the sizes and coefficients listed. For example: | ||
158 | numa=fake=2*512,1024,4*256,*128 | ||
159 | gives two 512M nodes, a 1024M node, four 256M nodes, and the | ||
160 | rest split into 128M chunks. If the last character of CMDLINE | ||
161 | is a *, the remaining memory is divided up equally among its | ||
162 | coefficient: | ||
163 | numa=fake=2*512,2* | ||
164 | gives two 512M nodes and the rest split into two nodes. | ||
165 | Otherwise, the remaining system RAM is allocated to an | ||
166 | additional node. | ||
167 | |||
168 | numa=hotadd=percent | ||
169 | Only allow hotadd memory to preallocate page structures upto | ||
170 | percent of already available memory. | ||
171 | numa=hotadd=0 will disable hotadd memory. | ||
172 | |||
173 | ACPI | ||
174 | |||
175 | acpi=off Don't enable ACPI | ||
176 | acpi=ht Use ACPI boot table parsing, but don't enable ACPI | ||
177 | interpreter | ||
178 | acpi=force Force ACPI on (currently not needed) | ||
179 | |||
180 | acpi=strict Disable out of spec ACPI workarounds. | ||
181 | |||
182 | acpi_sci={edge,level,high,low} Set up ACPI SCI interrupt. | ||
183 | |||
184 | acpi=noirq Don't route interrupts | ||
185 | |||
186 | PCI | ||
187 | |||
188 | pci=off Don't use PCI | ||
189 | pci=conf1 Use conf1 access. | ||
190 | pci=conf2 Use conf2 access. | ||
191 | pci=rom Assign ROMs. | ||
192 | pci=assign-busses Assign busses | ||
193 | pci=irqmask=MASK Set PCI interrupt mask to MASK | ||
194 | pci=lastbus=NUMBER Scan upto NUMBER busses, no matter what the mptable says. | ||
195 | pci=noacpi Don't use ACPI to set up PCI interrupt routing. | ||
196 | |||
197 | IOMMU (input/output memory management unit) | ||
198 | |||
199 | Currently four x86-64 PCI-DMA mapping implementations exist: | ||
200 | |||
201 | 1. <arch/x86_64/kernel/pci-nommu.c>: use no hardware/software IOMMU at all | ||
202 | (e.g. because you have < 3 GB memory). | ||
203 | Kernel boot message: "PCI-DMA: Disabling IOMMU" | ||
204 | |||
205 | 2. <arch/x86_64/kernel/pci-gart.c>: AMD GART based hardware IOMMU. | ||
206 | Kernel boot message: "PCI-DMA: using GART IOMMU" | ||
207 | |||
208 | 3. <arch/x86_64/kernel/pci-swiotlb.c> : Software IOMMU implementation. Used | ||
209 | e.g. if there is no hardware IOMMU in the system and it is need because | ||
210 | you have >3GB memory or told the kernel to us it (iommu=soft)) | ||
211 | Kernel boot message: "PCI-DMA: Using software bounce buffering | ||
212 | for IO (SWIOTLB)" | ||
213 | |||
214 | 4. <arch/x86_64/pci-calgary.c> : IBM Calgary hardware IOMMU. Used in IBM | ||
215 | pSeries and xSeries servers. This hardware IOMMU supports DMA address | ||
216 | mapping with memory protection, etc. | ||
217 | Kernel boot message: "PCI-DMA: Using Calgary IOMMU" | ||
218 | |||
219 | iommu=[<size>][,noagp][,off][,force][,noforce][,leak[=<nr_of_leak_pages>] | ||
220 | [,memaper[=<order>]][,merge][,forcesac][,fullflush][,nomerge] | ||
221 | [,noaperture][,calgary] | ||
222 | |||
223 | General iommu options: | ||
224 | off Don't initialize and use any kind of IOMMU. | ||
225 | noforce Don't force hardware IOMMU usage when it is not needed. | ||
226 | (default). | ||
227 | force Force the use of the hardware IOMMU even when it is | ||
228 | not actually needed (e.g. because < 3 GB memory). | ||
229 | soft Use software bounce buffering (SWIOTLB) (default for | ||
230 | Intel machines). This can be used to prevent the usage | ||
231 | of an available hardware IOMMU. | ||
232 | |||
233 | iommu options only relevant to the AMD GART hardware IOMMU: | ||
234 | <size> Set the size of the remapping area in bytes. | ||
235 | allowed Overwrite iommu off workarounds for specific chipsets. | ||
236 | fullflush Flush IOMMU on each allocation (default). | ||
237 | nofullflush Don't use IOMMU fullflush. | ||
238 | leak Turn on simple iommu leak tracing (only when | ||
239 | CONFIG_IOMMU_LEAK is on). Default number of leak pages | ||
240 | is 20. | ||
241 | memaper[=<order>] Allocate an own aperture over RAM with size 32MB<<order. | ||
242 | (default: order=1, i.e. 64MB) | ||
243 | merge Do scatter-gather (SG) merging. Implies "force" | ||
244 | (experimental). | ||
245 | nomerge Don't do scatter-gather (SG) merging. | ||
246 | noaperture Ask the IOMMU not to touch the aperture for AGP. | ||
247 | forcesac Force single-address cycle (SAC) mode for masks <40bits | ||
248 | (experimental). | ||
249 | noagp Don't initialize the AGP driver and use full aperture. | ||
250 | allowdac Allow double-address cycle (DAC) mode, i.e. DMA >4GB. | ||
251 | DAC is used with 32-bit PCI to push a 64-bit address in | ||
252 | two cycles. When off all DMA over >4GB is forced through | ||
253 | an IOMMU or software bounce buffering. | ||
254 | nodac Forbid DAC mode, i.e. DMA >4GB. | ||
255 | panic Always panic when IOMMU overflows. | ||
256 | calgary Use the Calgary IOMMU if it is available | ||
257 | |||
258 | iommu options only relevant to the software bounce buffering (SWIOTLB) IOMMU | ||
259 | implementation: | ||
260 | swiotlb=<pages>[,force] | ||
261 | <pages> Prereserve that many 128K pages for the software IO | ||
262 | bounce buffering. | ||
263 | force Force all IO through the software TLB. | ||
264 | |||
265 | Settings for the IBM Calgary hardware IOMMU currently found in IBM | ||
266 | pSeries and xSeries machines: | ||
267 | |||
268 | calgary=[64k,128k,256k,512k,1M,2M,4M,8M] | ||
269 | calgary=[translate_empty_slots] | ||
270 | calgary=[disable=<PCI bus number>] | ||
271 | panic Always panic when IOMMU overflows | ||
272 | |||
273 | 64k,...,8M - Set the size of each PCI slot's translation table | ||
274 | when using the Calgary IOMMU. This is the size of the translation | ||
275 | table itself in main memory. The smallest table, 64k, covers an IO | ||
276 | space of 32MB; the largest, 8MB table, can cover an IO space of | ||
277 | 4GB. Normally the kernel will make the right choice by itself. | ||
278 | |||
279 | translate_empty_slots - Enable translation even on slots that have | ||
280 | no devices attached to them, in case a device will be hotplugged | ||
281 | in the future. | ||
282 | |||
283 | disable=<PCI bus number> - Disable translation on a given PHB. For | ||
284 | example, the built-in graphics adapter resides on the first bridge | ||
285 | (PCI bus number 0); if translation (isolation) is enabled on this | ||
286 | bridge, X servers that access the hardware directly from user | ||
287 | space might stop working. Use this option if you have devices that | ||
288 | are accessed from userspace directly on some PCI host bridge. | ||
289 | |||
290 | Debugging | ||
291 | |||
292 | oops=panic Always panic on oopses. Default is to just kill the process, | ||
293 | but there is a small probability of deadlocking the machine. | ||
294 | This will also cause panics on machine check exceptions. | ||
295 | Useful together with panic=30 to trigger a reboot. | ||
296 | |||
297 | kstack=N Print N words from the kernel stack in oops dumps. | ||
298 | |||
299 | pagefaulttrace Dump all page faults. Only useful for extreme debugging | ||
300 | and will create a lot of output. | ||
301 | |||
302 | call_trace=[old|both|newfallback|new] | ||
303 | old: use old inexact backtracer | ||
304 | new: use new exact dwarf2 unwinder | ||
305 | both: print entries from both | ||
306 | newfallback: use new unwinder but fall back to old if it gets | ||
307 | stuck (default) | ||
308 | |||
309 | Miscellaneous | ||
310 | |||
311 | nogbpages | ||
312 | Do not use GB pages for kernel direct mappings. | ||
313 | gbpages | ||
314 | Use GB pages for kernel direct mappings. | ||
diff --git a/Documentation/x86/x86_64/cpu-hotplug-spec b/Documentation/x86/x86_64/cpu-hotplug-spec new file mode 100644 index 000000000000..3c23e0587db3 --- /dev/null +++ b/Documentation/x86/x86_64/cpu-hotplug-spec | |||
@@ -0,0 +1,21 @@ | |||
1 | Firmware support for CPU hotplug under Linux/x86-64 | ||
2 | --------------------------------------------------- | ||
3 | |||
4 | Linux/x86-64 supports CPU hotplug now. For various reasons Linux wants to | ||
5 | know in advance of boot time the maximum number of CPUs that could be plugged | ||
6 | into the system. ACPI 3.0 currently has no official way to supply | ||
7 | this information from the firmware to the operating system. | ||
8 | |||
9 | In ACPI each CPU needs an LAPIC object in the MADT table (5.2.11.5 in the | ||
10 | ACPI 3.0 specification). ACPI already has the concept of disabled LAPIC | ||
11 | objects by setting the Enabled bit in the LAPIC object to zero. | ||
12 | |||
13 | For CPU hotplug Linux/x86-64 expects now that any possible future hotpluggable | ||
14 | CPU is already available in the MADT. If the CPU is not available yet | ||
15 | it should have its LAPIC Enabled bit set to 0. Linux will use the number | ||
16 | of disabled LAPICs to compute the maximum number of future CPUs. | ||
17 | |||
18 | In the worst case the user can overwrite this choice using a command line | ||
19 | option (additional_cpus=...), but it is recommended to supply the correct | ||
20 | number (or a reasonable approximation of it, with erring towards more not less) | ||
21 | in the MADT to avoid manual configuration. | ||
diff --git a/Documentation/x86/x86_64/fake-numa-for-cpusets b/Documentation/x86/x86_64/fake-numa-for-cpusets new file mode 100644 index 000000000000..d1a985c5b00a --- /dev/null +++ b/Documentation/x86/x86_64/fake-numa-for-cpusets | |||
@@ -0,0 +1,66 @@ | |||
1 | Using numa=fake and CPUSets for Resource Management | ||
2 | Written by David Rientjes <rientjes@cs.washington.edu> | ||
3 | |||
4 | This document describes how the numa=fake x86_64 command-line option can be used | ||
5 | in conjunction with cpusets for coarse memory management. Using this feature, | ||
6 | you can create fake NUMA nodes that represent contiguous chunks of memory and | ||
7 | assign them to cpusets and their attached tasks. This is a way of limiting the | ||
8 | amount of system memory that are available to a certain class of tasks. | ||
9 | |||
10 | For more information on the features of cpusets, see Documentation/cpusets.txt. | ||
11 | There are a number of different configurations you can use for your needs. For | ||
12 | more information on the numa=fake command line option and its various ways of | ||
13 | configuring fake nodes, see Documentation/x86_64/boot-options.txt. | ||
14 | |||
15 | For the purposes of this introduction, we'll assume a very primitive NUMA | ||
16 | emulation setup of "numa=fake=4*512,". This will split our system memory into | ||
17 | four equal chunks of 512M each that we can now use to assign to cpusets. As | ||
18 | you become more familiar with using this combination for resource control, | ||
19 | you'll determine a better setup to minimize the number of nodes you have to deal | ||
20 | with. | ||
21 | |||
22 | A machine may be split as follows with "numa=fake=4*512," as reported by dmesg: | ||
23 | |||
24 | Faking node 0 at 0000000000000000-0000000020000000 (512MB) | ||
25 | Faking node 1 at 0000000020000000-0000000040000000 (512MB) | ||
26 | Faking node 2 at 0000000040000000-0000000060000000 (512MB) | ||
27 | Faking node 3 at 0000000060000000-0000000080000000 (512MB) | ||
28 | ... | ||
29 | On node 0 totalpages: 130975 | ||
30 | On node 1 totalpages: 131072 | ||
31 | On node 2 totalpages: 131072 | ||
32 | On node 3 totalpages: 131072 | ||
33 | |||
34 | Now following the instructions for mounting the cpusets filesystem from | ||
35 | Documentation/cpusets.txt, you can assign fake nodes (i.e. contiguous memory | ||
36 | address spaces) to individual cpusets: | ||
37 | |||
38 | [root@xroads /]# mkdir exampleset | ||
39 | [root@xroads /]# mount -t cpuset none exampleset | ||
40 | [root@xroads /]# mkdir exampleset/ddset | ||
41 | [root@xroads /]# cd exampleset/ddset | ||
42 | [root@xroads /exampleset/ddset]# echo 0-1 > cpus | ||
43 | [root@xroads /exampleset/ddset]# echo 0-1 > mems | ||
44 | |||
45 | Now this cpuset, 'ddset', will only allowed access to fake nodes 0 and 1 for | ||
46 | memory allocations (1G). | ||
47 | |||
48 | You can now assign tasks to these cpusets to limit the memory resources | ||
49 | available to them according to the fake nodes assigned as mems: | ||
50 | |||
51 | [root@xroads /exampleset/ddset]# echo $$ > tasks | ||
52 | [root@xroads /exampleset/ddset]# dd if=/dev/zero of=tmp bs=1024 count=1G | ||
53 | [1] 13425 | ||
54 | |||
55 | Notice the difference between the system memory usage as reported by | ||
56 | /proc/meminfo between the restricted cpuset case above and the unrestricted | ||
57 | case (i.e. running the same 'dd' command without assigning it to a fake NUMA | ||
58 | cpuset): | ||
59 | Unrestricted Restricted | ||
60 | MemTotal: 3091900 kB 3091900 kB | ||
61 | MemFree: 42113 kB 1513236 kB | ||
62 | |||
63 | This allows for coarse memory management for the tasks you assign to particular | ||
64 | cpusets. Since cpusets can form a hierarchy, you can create some pretty | ||
65 | interesting combinations of use-cases for various classes of tasks for your | ||
66 | memory management needs. | ||
diff --git a/Documentation/x86/x86_64/kernel-stacks b/Documentation/x86/x86_64/kernel-stacks new file mode 100644 index 000000000000..5ad65d51fb95 --- /dev/null +++ b/Documentation/x86/x86_64/kernel-stacks | |||
@@ -0,0 +1,99 @@ | |||
1 | Most of the text from Keith Owens, hacked by AK | ||
2 | |||
3 | x86_64 page size (PAGE_SIZE) is 4K. | ||
4 | |||
5 | Like all other architectures, x86_64 has a kernel stack for every | ||
6 | active thread. These thread stacks are THREAD_SIZE (2*PAGE_SIZE) big. | ||
7 | These stacks contain useful data as long as a thread is alive or a | ||
8 | zombie. While the thread is in user space the kernel stack is empty | ||
9 | except for the thread_info structure at the bottom. | ||
10 | |||
11 | In addition to the per thread stacks, there are specialized stacks | ||
12 | associated with each CPU. These stacks are only used while the kernel | ||
13 | is in control on that CPU; when a CPU returns to user space the | ||
14 | specialized stacks contain no useful data. The main CPU stacks are: | ||
15 | |||
16 | * Interrupt stack. IRQSTACKSIZE | ||
17 | |||
18 | Used for external hardware interrupts. If this is the first external | ||
19 | hardware interrupt (i.e. not a nested hardware interrupt) then the | ||
20 | kernel switches from the current task to the interrupt stack. Like | ||
21 | the split thread and interrupt stacks on i386 (with CONFIG_4KSTACKS), | ||
22 | this gives more room for kernel interrupt processing without having | ||
23 | to increase the size of every per thread stack. | ||
24 | |||
25 | The interrupt stack is also used when processing a softirq. | ||
26 | |||
27 | Switching to the kernel interrupt stack is done by software based on a | ||
28 | per CPU interrupt nest counter. This is needed because x86-64 "IST" | ||
29 | hardware stacks cannot nest without races. | ||
30 | |||
31 | x86_64 also has a feature which is not available on i386, the ability | ||
32 | to automatically switch to a new stack for designated events such as | ||
33 | double fault or NMI, which makes it easier to handle these unusual | ||
34 | events on x86_64. This feature is called the Interrupt Stack Table | ||
35 | (IST). There can be up to 7 IST entries per CPU. The IST code is an | ||
36 | index into the Task State Segment (TSS). The IST entries in the TSS | ||
37 | point to dedicated stacks; each stack can be a different size. | ||
38 | |||
39 | An IST is selected by a non-zero value in the IST field of an | ||
40 | interrupt-gate descriptor. When an interrupt occurs and the hardware | ||
41 | loads such a descriptor, the hardware automatically sets the new stack | ||
42 | pointer based on the IST value, then invokes the interrupt handler. If | ||
43 | software wants to allow nested IST interrupts then the handler must | ||
44 | adjust the IST values on entry to and exit from the interrupt handler. | ||
45 | (This is occasionally done, e.g. for debug exceptions.) | ||
46 | |||
47 | Events with different IST codes (i.e. with different stacks) can be | ||
48 | nested. For example, a debug interrupt can safely be interrupted by an | ||
49 | NMI. arch/x86_64/kernel/entry.S::paranoidentry adjusts the stack | ||
50 | pointers on entry to and exit from all IST events, in theory allowing | ||
51 | IST events with the same code to be nested. However in most cases, the | ||
52 | stack size allocated to an IST assumes no nesting for the same code. | ||
53 | If that assumption is ever broken then the stacks will become corrupt. | ||
54 | |||
55 | The currently assigned IST stacks are :- | ||
56 | |||
57 | * STACKFAULT_STACK. EXCEPTION_STKSZ (PAGE_SIZE). | ||
58 | |||
59 | Used for interrupt 12 - Stack Fault Exception (#SS). | ||
60 | |||
61 | This allows the CPU to recover from invalid stack segments. Rarely | ||
62 | happens. | ||
63 | |||
64 | * DOUBLEFAULT_STACK. EXCEPTION_STKSZ (PAGE_SIZE). | ||
65 | |||
66 | Used for interrupt 8 - Double Fault Exception (#DF). | ||
67 | |||
68 | Invoked when handling one exception causes another exception. Happens | ||
69 | when the kernel is very confused (e.g. kernel stack pointer corrupt). | ||
70 | Using a separate stack allows the kernel to recover from it well enough | ||
71 | in many cases to still output an oops. | ||
72 | |||
73 | * NMI_STACK. EXCEPTION_STKSZ (PAGE_SIZE). | ||
74 | |||
75 | Used for non-maskable interrupts (NMI). | ||
76 | |||
77 | NMI can be delivered at any time, including when the kernel is in the | ||
78 | middle of switching stacks. Using IST for NMI events avoids making | ||
79 | assumptions about the previous state of the kernel stack. | ||
80 | |||
81 | * DEBUG_STACK. DEBUG_STKSZ | ||
82 | |||
83 | Used for hardware debug interrupts (interrupt 1) and for software | ||
84 | debug interrupts (INT3). | ||
85 | |||
86 | When debugging a kernel, debug interrupts (both hardware and | ||
87 | software) can occur at any time. Using IST for these interrupts | ||
88 | avoids making assumptions about the previous state of the kernel | ||
89 | stack. | ||
90 | |||
91 | * MCE_STACK. EXCEPTION_STKSZ (PAGE_SIZE). | ||
92 | |||
93 | Used for interrupt 18 - Machine Check Exception (#MC). | ||
94 | |||
95 | MCE can be delivered at any time, including when the kernel is in the | ||
96 | middle of switching stacks. Using IST for MCE events avoids making | ||
97 | assumptions about the previous state of the kernel stack. | ||
98 | |||
99 | For more details see the Intel IA32 or AMD AMD64 architecture manuals. | ||
diff --git a/Documentation/x86/x86_64/machinecheck b/Documentation/x86/x86_64/machinecheck new file mode 100644 index 000000000000..a05e58e7b159 --- /dev/null +++ b/Documentation/x86/x86_64/machinecheck | |||
@@ -0,0 +1,77 @@ | |||
1 | |||
2 | Configurable sysfs parameters for the x86-64 machine check code. | ||
3 | |||
4 | Machine checks report internal hardware error conditions detected | ||
5 | by the CPU. Uncorrected errors typically cause a machine check | ||
6 | (often with panic), corrected ones cause a machine check log entry. | ||
7 | |||
8 | Machine checks are organized in banks (normally associated with | ||
9 | a hardware subsystem) and subevents in a bank. The exact meaning | ||
10 | of the banks and subevent is CPU specific. | ||
11 | |||
12 | mcelog knows how to decode them. | ||
13 | |||
14 | When you see the "Machine check errors logged" message in the system | ||
15 | log then mcelog should run to collect and decode machine check entries | ||
16 | from /dev/mcelog. Normally mcelog should be run regularly from a cronjob. | ||
17 | |||
18 | Each CPU has a directory in /sys/devices/system/machinecheck/machinecheckN | ||
19 | (N = CPU number) | ||
20 | |||
21 | The directory contains some configurable entries: | ||
22 | |||
23 | Entries: | ||
24 | |||
25 | bankNctl | ||
26 | (N bank number) | ||
27 | 64bit Hex bitmask enabling/disabling specific subevents for bank N | ||
28 | When a bit in the bitmask is zero then the respective | ||
29 | subevent will not be reported. | ||
30 | By default all events are enabled. | ||
31 | Note that BIOS maintain another mask to disable specific events | ||
32 | per bank. This is not visible here | ||
33 | |||
34 | The following entries appear for each CPU, but they are truly shared | ||
35 | between all CPUs. | ||
36 | |||
37 | check_interval | ||
38 | How often to poll for corrected machine check errors, in seconds | ||
39 | (Note output is hexademical). Default 5 minutes. When the poller | ||
40 | finds MCEs it triggers an exponential speedup (poll more often) on | ||
41 | the polling interval. When the poller stops finding MCEs, it | ||
42 | triggers an exponential backoff (poll less often) on the polling | ||
43 | interval. The check_interval variable is both the initial and | ||
44 | maximum polling interval. | ||
45 | |||
46 | tolerant | ||
47 | Tolerance level. When a machine check exception occurs for a non | ||
48 | corrected machine check the kernel can take different actions. | ||
49 | Since machine check exceptions can happen any time it is sometimes | ||
50 | risky for the kernel to kill a process because it defies | ||
51 | normal kernel locking rules. The tolerance level configures | ||
52 | how hard the kernel tries to recover even at some risk of | ||
53 | deadlock. Higher tolerant values trade potentially better uptime | ||
54 | with the risk of a crash or even corruption (for tolerant >= 3). | ||
55 | |||
56 | 0: always panic on uncorrected errors, log corrected errors | ||
57 | 1: panic or SIGBUS on uncorrected errors, log corrected errors | ||
58 | 2: SIGBUS or log uncorrected errors, log corrected errors | ||
59 | 3: never panic or SIGBUS, log all errors (for testing only) | ||
60 | |||
61 | Default: 1 | ||
62 | |||
63 | Note this only makes a difference if the CPU allows recovery | ||
64 | from a machine check exception. Current x86 CPUs generally do not. | ||
65 | |||
66 | trigger | ||
67 | Program to run when a machine check event is detected. | ||
68 | This is an alternative to running mcelog regularly from cron | ||
69 | and allows to detect events faster. | ||
70 | |||
71 | TBD document entries for AMD threshold interrupt configuration | ||
72 | |||
73 | For more details about the x86 machine check architecture | ||
74 | see the Intel and AMD architecture manuals from their developer websites. | ||
75 | |||
76 | For more details about the architecture see | ||
77 | see http://one.firstfloor.org/~andi/mce.pdf | ||
diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt new file mode 100644 index 000000000000..efce75097369 --- /dev/null +++ b/Documentation/x86/x86_64/mm.txt | |||
@@ -0,0 +1,28 @@ | |||
1 | |||
2 | <previous description obsolete, deleted> | ||
3 | |||
4 | Virtual memory map with 4 level page tables: | ||
5 | |||
6 | 0000000000000000 - 00007fffffffffff (=47 bits) user space, different per mm | ||
7 | hole caused by [48:63] sign extension | ||
8 | ffff800000000000 - ffff80ffffffffff (=40 bits) guard hole | ||
9 | ffff810000000000 - ffffc0ffffffffff (=46 bits) direct mapping of all phys. memory | ||
10 | ffffc10000000000 - ffffc1ffffffffff (=40 bits) hole | ||
11 | ffffc20000000000 - ffffe1ffffffffff (=45 bits) vmalloc/ioremap space | ||
12 | ffffe20000000000 - ffffe2ffffffffff (=40 bits) virtual memory map (1TB) | ||
13 | ... unused hole ... | ||
14 | ffffffff80000000 - ffffffffa0000000 (=512 MB) kernel text mapping, from phys 0 | ||
15 | ffffffffa0000000 - fffffffffff00000 (=1536 MB) module mapping space | ||
16 | |||
17 | The direct mapping covers all memory in the system up to the highest | ||
18 | memory address (this means in some cases it can also include PCI memory | ||
19 | holes). | ||
20 | |||
21 | vmalloc space is lazily synchronized into the different PML4 pages of | ||
22 | the processes using the page fault handler, with init_level4_pgt as | ||
23 | reference. | ||
24 | |||
25 | Current X86-64 implementations only support 40 bits of address space, | ||
26 | but we support up to 46 bits. This expands into MBZ space in the page tables. | ||
27 | |||
28 | -Andi Kleen, Jul 2004 | ||
diff --git a/Documentation/x86/x86_64/uefi.txt b/Documentation/x86/x86_64/uefi.txt new file mode 100644 index 000000000000..a5e2b4fdb170 --- /dev/null +++ b/Documentation/x86/x86_64/uefi.txt | |||
@@ -0,0 +1,42 @@ | |||
1 | General note on [U]EFI x86_64 support | ||
2 | ------------------------------------- | ||
3 | |||
4 | The nomenclature EFI and UEFI are used interchangeably in this document. | ||
5 | |||
6 | Although the tools below are _not_ needed for building the kernel, | ||
7 | the needed bootloader support and associated tools for x86_64 platforms | ||
8 | with EFI firmware and specifications are listed below. | ||
9 | |||
10 | 1. UEFI specification: http://www.uefi.org | ||
11 | |||
12 | 2. Booting Linux kernel on UEFI x86_64 platform requires bootloader | ||
13 | support. Elilo with x86_64 support can be used. | ||
14 | |||
15 | 3. x86_64 platform with EFI/UEFI firmware. | ||
16 | |||
17 | Mechanics: | ||
18 | --------- | ||
19 | - Build the kernel with the following configuration. | ||
20 | CONFIG_FB_EFI=y | ||
21 | CONFIG_FRAMEBUFFER_CONSOLE=y | ||
22 | If EFI runtime services are expected, the following configuration should | ||
23 | be selected. | ||
24 | CONFIG_EFI=y | ||
25 | CONFIG_EFI_VARS=y or m # optional | ||
26 | - Create a VFAT partition on the disk | ||
27 | - Copy the following to the VFAT partition: | ||
28 | elilo bootloader with x86_64 support, elilo configuration file, | ||
29 | kernel image built in first step and corresponding | ||
30 | initrd. Instructions on building elilo and its dependencies | ||
31 | can be found in the elilo sourceforge project. | ||
32 | - Boot to EFI shell and invoke elilo choosing the kernel image built | ||
33 | in first step. | ||
34 | - If some or all EFI runtime services don't work, you can try following | ||
35 | kernel command line parameters to turn off some or all EFI runtime | ||
36 | services. | ||
37 | noefi turn off all EFI runtime services | ||
38 | reboot_type=k turn off EFI reboot runtime service | ||
39 | - If the EFI memory map has additional entries not in the E820 map, | ||
40 | you can include those entries in the kernels memory map of available | ||
41 | physical RAM by using the following kernel command line parameter. | ||
42 | add_efi_memmap include EFI memory map of available physical RAM | ||