Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
tjh.dev
kernel
os
linux
1# SPDX-License-Identifier: GPL-2.0
2menu "Kernel hacking"
3
4config TRACE_IRQFLAGS_SUPPORT
5 def_bool y
6
7source "lib/Kconfig.debug"
8
9config EARLY_PRINTK_USB
10 bool
11
12config X86_VERBOSE_BOOTUP
13 bool "Enable verbose x86 bootup info messages"
14 default y
15 ---help---
16 Enables the informational output from the decompression stage
17 (e.g. bzImage) of the boot. If you disable this you will still
18 see errors. Disable this if you want silent bootup.
19
20config EARLY_PRINTK
21 bool "Early printk" if EXPERT
22 default y
23 ---help---
24 Write kernel log output directly into the VGA buffer or to a serial
25 port.
26
27 This is useful for kernel debugging when your machine crashes very
28 early before the console code is initialized. For normal operation
29 it is not recommended because it looks ugly and doesn't cooperate
30 with klogd/syslogd or the X server. You should normally say N here,
31 unless you want to debug such a crash.
32
33config EARLY_PRINTK_DBGP
34 bool "Early printk via EHCI debug port"
35 depends on EARLY_PRINTK && PCI
36 select EARLY_PRINTK_USB
37 ---help---
38 Write kernel log output directly into the EHCI debug port.
39
40 This is useful for kernel debugging when your machine crashes very
41 early before the console code is initialized. For normal operation
42 it is not recommended because it looks ugly and doesn't cooperate
43 with klogd/syslogd or the X server. You should normally say N here,
44 unless you want to debug such a crash. You need usb debug device.
45
46config EARLY_PRINTK_EFI
47 bool "Early printk via the EFI framebuffer"
48 depends on EFI && EARLY_PRINTK
49 select FONT_SUPPORT
50 ---help---
51 Write kernel log output directly into the EFI framebuffer.
52
53 This is useful for kernel debugging when your machine crashes very
54 early before the console code is initialized.
55
56config EARLY_PRINTK_USB_XDBC
57 bool "Early printk via the xHCI debug port"
58 depends on EARLY_PRINTK && PCI
59 select EARLY_PRINTK_USB
60 ---help---
61 Write kernel log output directly into the xHCI debug port.
62
63 One use for this feature is kernel debugging, for example when your
64 machine crashes very early before the regular console code is
65 initialized. Other uses include simpler, lockless logging instead of
66 a full-blown printk console driver + klogd.
67
68 For normal production environments this is normally not recommended,
69 because it doesn't feed events into klogd/syslogd and doesn't try to
70 print anything on the screen.
71
72 You should normally say N here, unless you want to debug early
73 crashes or need a very simple printk logging facility.
74
75config MCSAFE_TEST
76 def_bool n
77
78config X86_PTDUMP_CORE
79 def_bool n
80
81config X86_PTDUMP
82 tristate "Export kernel pagetable layout to userspace via debugfs"
83 depends on DEBUG_KERNEL
84 select DEBUG_FS
85 select X86_PTDUMP_CORE
86 ---help---
87 Say Y here if you want to show the kernel pagetable layout in a
88 debugfs file. This information is only useful for kernel developers
89 who are working in architecture specific areas of the kernel.
90 It is probably not a good idea to enable this feature in a production
91 kernel.
92 If in doubt, say "N"
93
94config EFI_PGT_DUMP
95 bool "Dump the EFI pagetable"
96 depends on EFI
97 select X86_PTDUMP_CORE
98 ---help---
99 Enable this if you want to dump the EFI page table before
100 enabling virtual mode. This can be used to debug miscellaneous
101 issues with the mapping of the EFI runtime regions into that
102 table.
103
104config DEBUG_WX
105 bool "Warn on W+X mappings at boot"
106 select X86_PTDUMP_CORE
107 ---help---
108 Generate a warning if any W+X mappings are found at boot.
109
110 This is useful for discovering cases where the kernel is leaving
111 W+X mappings after applying NX, as such mappings are a security risk.
112
113 Look for a message in dmesg output like this:
114
115 x86/mm: Checked W+X mappings: passed, no W+X pages found.
116
117 or like this, if the check failed:
118
119 x86/mm: Checked W+X mappings: FAILED, <N> W+X pages found.
120
121 Note that even if the check fails, your kernel is possibly
122 still fine, as W+X mappings are not a security hole in
123 themselves, what they do is that they make the exploitation
124 of other unfixed kernel bugs easier.
125
126 There is no runtime or memory usage effect of this option
127 once the kernel has booted up - it's a one time check.
128
129 If in doubt, say "Y".
130
131config DOUBLEFAULT
132 default y
133 bool "Enable doublefault exception handler" if EXPERT
134 ---help---
135 This option allows trapping of rare doublefault exceptions that
136 would otherwise cause a system to silently reboot. Disabling this
137 option saves about 4k and might cause you much additional grey
138 hair.
139
140config DEBUG_TLBFLUSH
141 bool "Set upper limit of TLB entries to flush one-by-one"
142 depends on DEBUG_KERNEL
143 ---help---
144
145 X86-only for now.
146
147 This option allows the user to tune the amount of TLB entries the
148 kernel flushes one-by-one instead of doing a full TLB flush. In
149 certain situations, the former is cheaper. This is controlled by the
150 tlb_flushall_shift knob under /sys/kernel/debug/x86. If you set it
151 to -1, the code flushes the whole TLB unconditionally. Otherwise,
152 for positive values of it, the kernel will use single TLB entry
153 invalidating instructions according to the following formula:
154
155 flush_entries <= active_tlb_entries / 2^tlb_flushall_shift
156
157 If in doubt, say "N".
158
159config IOMMU_DEBUG
160 bool "Enable IOMMU debugging"
161 depends on GART_IOMMU && DEBUG_KERNEL
162 depends on X86_64
163 ---help---
164 Force the IOMMU to on even when you have less than 4GB of
165 memory and add debugging code. On overflow always panic. And
166 allow to enable IOMMU leak tracing. Can be disabled at boot
167 time with iommu=noforce. This will also enable scatter gather
168 list merging. Currently not recommended for production
169 code. When you use it make sure you have a big enough
170 IOMMU/AGP aperture. Most of the options enabled by this can
171 be set more finegrained using the iommu= command line
172 options. See Documentation/x86/x86_64/boot-options.txt for more
173 details.
174
175config IOMMU_LEAK
176 bool "IOMMU leak tracing"
177 depends on IOMMU_DEBUG && DMA_API_DEBUG
178 ---help---
179 Add a simple leak tracer to the IOMMU code. This is useful when you
180 are debugging a buggy device driver that leaks IOMMU mappings.
181
182config HAVE_MMIOTRACE_SUPPORT
183 def_bool y
184
185config X86_DECODER_SELFTEST
186 bool "x86 instruction decoder selftest"
187 depends on DEBUG_KERNEL && KPROBES
188 depends on !COMPILE_TEST
189 ---help---
190 Perform x86 instruction decoder selftests at build time.
191 This option is useful for checking the sanity of x86 instruction
192 decoder code.
193 If unsure, say "N".
194
195#
196# IO delay types:
197#
198
199config IO_DELAY_TYPE_0X80
200 int
201 default "0"
202
203config IO_DELAY_TYPE_0XED
204 int
205 default "1"
206
207config IO_DELAY_TYPE_UDELAY
208 int
209 default "2"
210
211config IO_DELAY_TYPE_NONE
212 int
213 default "3"
214
215choice
216 prompt "IO delay type"
217 default IO_DELAY_0X80
218
219config IO_DELAY_0X80
220 bool "port 0x80 based port-IO delay [recommended]"
221 ---help---
222 This is the traditional Linux IO delay used for in/out_p.
223 It is the most tested hence safest selection here.
224
225config IO_DELAY_0XED
226 bool "port 0xed based port-IO delay"
227 ---help---
228 Use port 0xed as the IO delay. This frees up port 0x80 which is
229 often used as a hardware-debug port.
230
231config IO_DELAY_UDELAY
232 bool "udelay based port-IO delay"
233 ---help---
234 Use udelay(2) as the IO delay method. This provides the delay
235 while not having any side-effect on the IO port space.
236
237config IO_DELAY_NONE
238 bool "no port-IO delay"
239 ---help---
240 No port-IO delay. Will break on old boxes that require port-IO
241 delay for certain operations. Should work on most new machines.
242
243endchoice
244
245if IO_DELAY_0X80
246config DEFAULT_IO_DELAY_TYPE
247 int
248 default IO_DELAY_TYPE_0X80
249endif
250
251if IO_DELAY_0XED
252config DEFAULT_IO_DELAY_TYPE
253 int
254 default IO_DELAY_TYPE_0XED
255endif
256
257if IO_DELAY_UDELAY
258config DEFAULT_IO_DELAY_TYPE
259 int
260 default IO_DELAY_TYPE_UDELAY
261endif
262
263if IO_DELAY_NONE
264config DEFAULT_IO_DELAY_TYPE
265 int
266 default IO_DELAY_TYPE_NONE
267endif
268
269config DEBUG_BOOT_PARAMS
270 bool "Debug boot parameters"
271 depends on DEBUG_KERNEL
272 depends on DEBUG_FS
273 ---help---
274 This option will cause struct boot_params to be exported via debugfs.
275
276config CPA_DEBUG
277 bool "CPA self-test code"
278 depends on DEBUG_KERNEL
279 ---help---
280 Do change_page_attr() self-tests every 30 seconds.
281
282config OPTIMIZE_INLINING
283 bool "Allow gcc to uninline functions marked 'inline'"
284 ---help---
285 This option determines if the kernel forces gcc to inline the functions
286 developers have marked 'inline'. Doing so takes away freedom from gcc to
287 do what it thinks is best, which is desirable for the gcc 3.x series of
288 compilers. The gcc 4.x series have a rewritten inlining algorithm and
289 enabling this option will generate a smaller kernel there. Hopefully
290 this algorithm is so good that allowing gcc 4.x and above to make the
291 decision will become the default in the future. Until then this option
292 is there to test gcc for this.
293
294 If unsure, say N.
295
296config DEBUG_ENTRY
297 bool "Debug low-level entry code"
298 depends on DEBUG_KERNEL
299 ---help---
300 This option enables sanity checks in x86's low-level entry code.
301 Some of these sanity checks may slow down kernel entries and
302 exits or otherwise impact performance.
303
304 If unsure, say N.
305
306config DEBUG_NMI_SELFTEST
307 bool "NMI Selftest"
308 depends on DEBUG_KERNEL && X86_LOCAL_APIC
309 ---help---
310 Enabling this option turns on a quick NMI selftest to verify
311 that the NMI behaves correctly.
312
313 This might help diagnose strange hangs that rely on NMI to
314 function properly.
315
316 If unsure, say N.
317
318config DEBUG_IMR_SELFTEST
319 bool "Isolated Memory Region self test"
320 default n
321 depends on INTEL_IMR
322 ---help---
323 This option enables automated sanity testing of the IMR code.
324 Some simple tests are run to verify IMR bounds checking, alignment
325 and overlapping. This option is really only useful if you are
326 debugging an IMR memory map or are modifying the IMR code and want to
327 test your changes.
328
329 If unsure say N here.
330
331config X86_DEBUG_FPU
332 bool "Debug the x86 FPU code"
333 depends on DEBUG_KERNEL
334 default y
335 ---help---
336 If this option is enabled then there will be extra sanity
337 checks and (boot time) debug printouts added to the kernel.
338 This debugging adds some small amount of runtime overhead
339 to the kernel.
340
341 If unsure, say N.
342
343config PUNIT_ATOM_DEBUG
344 tristate "ATOM Punit debug driver"
345 depends on PCI
346 select DEBUG_FS
347 select IOSF_MBI
348 ---help---
349 This is a debug driver, which gets the power states
350 of all Punit North Complex devices. The power states of
351 each device is exposed as part of the debugfs interface.
352 The current power state can be read from
353 /sys/kernel/debug/punit_atom/dev_power_state
354
355choice
356 prompt "Choose kernel unwinder"
357 default UNWINDER_ORC if X86_64
358 default UNWINDER_FRAME_POINTER if X86_32
359 ---help---
360 This determines which method will be used for unwinding kernel stack
361 traces for panics, oopses, bugs, warnings, perf, /proc/<pid>/stack,
362 livepatch, lockdep, and more.
363
364config UNWINDER_ORC
365 bool "ORC unwinder"
366 depends on X86_64
367 select STACK_VALIDATION
368 ---help---
369 This option enables the ORC (Oops Rewind Capability) unwinder for
370 unwinding kernel stack traces. It uses a custom data format which is
371 a simplified version of the DWARF Call Frame Information standard.
372
373 This unwinder is more accurate across interrupt entry frames than the
374 frame pointer unwinder. It also enables a 5-10% performance
375 improvement across the entire kernel compared to frame pointers.
376
377 Enabling this option will increase the kernel's runtime memory usage
378 by roughly 2-4MB, depending on your kernel config.
379
380config UNWINDER_FRAME_POINTER
381 bool "Frame pointer unwinder"
382 select FRAME_POINTER
383 ---help---
384 This option enables the frame pointer unwinder for unwinding kernel
385 stack traces.
386
387 The unwinder itself is fast and it uses less RAM than the ORC
388 unwinder, but the kernel text size will grow by ~3% and the kernel's
389 overall performance will degrade by roughly 5-10%.
390
391 This option is recommended if you want to use the livepatch
392 consistency model, as this is currently the only way to get a
393 reliable stack trace (CONFIG_HAVE_RELIABLE_STACKTRACE).
394
395config UNWINDER_GUESS
396 bool "Guess unwinder"
397 depends on EXPERT
398 depends on !STACKDEPOT
399 ---help---
400 This option enables the "guess" unwinder for unwinding kernel stack
401 traces. It scans the stack and reports every kernel text address it
402 finds. Some of the addresses it reports may be incorrect.
403
404 While this option often produces false positives, it can still be
405 useful in many cases. Unlike the other unwinders, it has no runtime
406 overhead.
407
408endchoice
409
410config FRAME_POINTER
411 depends on !UNWINDER_ORC && !UNWINDER_GUESS
412 bool
413
414endmenu