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