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