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_EFI 44 bool "Early printk via the EFI framebuffer" 45 depends on EFI && EARLY_PRINTK 46 select FONT_SUPPORT 47 ---help--- 48 Write kernel log output directly into the EFI framebuffer. 49 50 This is useful for kernel debugging when your machine crashes very 51 early before the console code is initialized. 52 53config EARLY_PRINTK_USB_XDBC 54 bool "Early printk via the xHCI debug port" 55 depends on EARLY_PRINTK && PCI 56 select EARLY_PRINTK_USB 57 ---help--- 58 Write kernel log output directly into the xHCI debug port. 59 60 One use for this feature is kernel debugging, for example when your 61 machine crashes very early before the regular console code is 62 initialized. Other uses include simpler, lockless logging instead of 63 a full-blown printk console driver + klogd. 64 65 For normal production environments this is normally not recommended, 66 because it doesn't feed events into klogd/syslogd and doesn't try to 67 print anything on the screen. 68 69 You should normally say N here, unless you want to debug early 70 crashes or need a very simple printk logging facility. 71 72config MCSAFE_TEST 73 def_bool n 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_LEAK 173 bool "IOMMU leak tracing" 174 depends on IOMMU_DEBUG && DMA_API_DEBUG 175 ---help--- 176 Add a simple leak tracer to the IOMMU code. This is useful when you 177 are debugging a buggy device driver that leaks IOMMU mappings. 178 179config HAVE_MMIOTRACE_SUPPORT 180 def_bool y 181 182config X86_DECODER_SELFTEST 183 bool "x86 instruction decoder selftest" 184 depends on DEBUG_KERNEL && KPROBES 185 depends on !COMPILE_TEST 186 ---help--- 187 Perform x86 instruction decoder selftests at build time. 188 This option is useful for checking the sanity of x86 instruction 189 decoder code. 190 If unsure, say "N". 191 192# 193# IO delay types: 194# 195 196config IO_DELAY_TYPE_0X80 197 int 198 default "0" 199 200config IO_DELAY_TYPE_0XED 201 int 202 default "1" 203 204config IO_DELAY_TYPE_UDELAY 205 int 206 default "2" 207 208config IO_DELAY_TYPE_NONE 209 int 210 default "3" 211 212choice 213 prompt "IO delay type" 214 default IO_DELAY_0X80 215 216config IO_DELAY_0X80 217 bool "port 0x80 based port-IO delay [recommended]" 218 ---help--- 219 This is the traditional Linux IO delay used for in/out_p. 220 It is the most tested hence safest selection here. 221 222config IO_DELAY_0XED 223 bool "port 0xed based port-IO delay" 224 ---help--- 225 Use port 0xed as the IO delay. This frees up port 0x80 which is 226 often used as a hardware-debug port. 227 228config IO_DELAY_UDELAY 229 bool "udelay based port-IO delay" 230 ---help--- 231 Use udelay(2) as the IO delay method. This provides the delay 232 while not having any side-effect on the IO port space. 233 234config IO_DELAY_NONE 235 bool "no port-IO delay" 236 ---help--- 237 No port-IO delay. Will break on old boxes that require port-IO 238 delay for certain operations. Should work on most new machines. 239 240endchoice 241 242if IO_DELAY_0X80 243config DEFAULT_IO_DELAY_TYPE 244 int 245 default IO_DELAY_TYPE_0X80 246endif 247 248if IO_DELAY_0XED 249config DEFAULT_IO_DELAY_TYPE 250 int 251 default IO_DELAY_TYPE_0XED 252endif 253 254if IO_DELAY_UDELAY 255config DEFAULT_IO_DELAY_TYPE 256 int 257 default IO_DELAY_TYPE_UDELAY 258endif 259 260if IO_DELAY_NONE 261config DEFAULT_IO_DELAY_TYPE 262 int 263 default IO_DELAY_TYPE_NONE 264endif 265 266config DEBUG_BOOT_PARAMS 267 bool "Debug boot parameters" 268 depends on DEBUG_KERNEL 269 depends on DEBUG_FS 270 ---help--- 271 This option will cause struct boot_params to be exported via debugfs. 272 273config CPA_DEBUG 274 bool "CPA self-test code" 275 depends on DEBUG_KERNEL 276 ---help--- 277 Do change_page_attr() self-tests every 30 seconds. 278 279config OPTIMIZE_INLINING 280 bool "Allow gcc to uninline functions marked 'inline'" 281 ---help--- 282 This option determines if the kernel forces gcc to inline the functions 283 developers have marked 'inline'. Doing so takes away freedom from gcc to 284 do what it thinks is best, which is desirable for the gcc 3.x series of 285 compilers. The gcc 4.x series have a rewritten inlining algorithm and 286 enabling this option will generate a smaller kernel there. Hopefully 287 this algorithm is so good that allowing gcc 4.x and above to make the 288 decision will become the default in the future. Until then this option 289 is there to test gcc for this. 290 291 If unsure, say N. 292 293config DEBUG_ENTRY 294 bool "Debug low-level entry code" 295 depends on DEBUG_KERNEL 296 ---help--- 297 This option enables sanity checks in x86's low-level entry code. 298 Some of these sanity checks may slow down kernel entries and 299 exits or otherwise impact performance. 300 301 If unsure, say N. 302 303config DEBUG_NMI_SELFTEST 304 bool "NMI Selftest" 305 depends on DEBUG_KERNEL && X86_LOCAL_APIC 306 ---help--- 307 Enabling this option turns on a quick NMI selftest to verify 308 that the NMI behaves correctly. 309 310 This might help diagnose strange hangs that rely on NMI to 311 function properly. 312 313 If unsure, say N. 314 315config DEBUG_IMR_SELFTEST 316 bool "Isolated Memory Region self test" 317 default n 318 depends on INTEL_IMR 319 ---help--- 320 This option enables automated sanity testing of the IMR code. 321 Some simple tests are run to verify IMR bounds checking, alignment 322 and overlapping. This option is really only useful if you are 323 debugging an IMR memory map or are modifying the IMR code and want to 324 test your changes. 325 326 If unsure say N here. 327 328config X86_DEBUG_FPU 329 bool "Debug the x86 FPU code" 330 depends on DEBUG_KERNEL 331 default y 332 ---help--- 333 If this option is enabled then there will be extra sanity 334 checks and (boot time) debug printouts added to the kernel. 335 This debugging adds some small amount of runtime overhead 336 to the kernel. 337 338 If unsure, say N. 339 340config PUNIT_ATOM_DEBUG 341 tristate "ATOM Punit debug driver" 342 depends on PCI 343 select DEBUG_FS 344 select IOSF_MBI 345 ---help--- 346 This is a debug driver, which gets the power states 347 of all Punit North Complex devices. The power states of 348 each device is exposed as part of the debugfs interface. 349 The current power state can be read from 350 /sys/kernel/debug/punit_atom/dev_power_state 351 352choice 353 prompt "Choose kernel unwinder" 354 default UNWINDER_ORC if X86_64 355 default UNWINDER_FRAME_POINTER if X86_32 356 ---help--- 357 This determines which method will be used for unwinding kernel stack 358 traces for panics, oopses, bugs, warnings, perf, /proc/<pid>/stack, 359 livepatch, lockdep, and more. 360 361config UNWINDER_ORC 362 bool "ORC unwinder" 363 depends on X86_64 364 select STACK_VALIDATION 365 ---help--- 366 This option enables the ORC (Oops Rewind Capability) unwinder for 367 unwinding kernel stack traces. It uses a custom data format which is 368 a simplified version of the DWARF Call Frame Information standard. 369 370 This unwinder is more accurate across interrupt entry frames than the 371 frame pointer unwinder. It also enables a 5-10% performance 372 improvement across the entire kernel compared to frame pointers. 373 374 Enabling this option will increase the kernel's runtime memory usage 375 by roughly 2-4MB, depending on your kernel config. 376 377config UNWINDER_FRAME_POINTER 378 bool "Frame pointer unwinder" 379 select FRAME_POINTER 380 ---help--- 381 This option enables the frame pointer unwinder for unwinding kernel 382 stack traces. 383 384 The unwinder itself is fast and it uses less RAM than the ORC 385 unwinder, but the kernel text size will grow by ~3% and the kernel's 386 overall performance will degrade by roughly 5-10%. 387 388 This option is recommended if you want to use the livepatch 389 consistency model, as this is currently the only way to get a 390 reliable stack trace (CONFIG_HAVE_RELIABLE_STACKTRACE). 391 392config UNWINDER_GUESS 393 bool "Guess unwinder" 394 depends on EXPERT 395 depends on !STACKDEPOT 396 ---help--- 397 This option enables the "guess" unwinder for unwinding kernel stack 398 traces. It scans the stack and reports every kernel text address it 399 finds. Some of the addresses it reports may be incorrect. 400 401 While this option often produces false positives, it can still be 402 useful in many cases. Unlike the other unwinders, it has no runtime 403 overhead. 404 405endchoice 406 407config FRAME_POINTER 408 depends on !UNWINDER_ORC && !UNWINDER_GUESS 409 bool 410