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 EFI_PGT_DUMP 66 bool "Dump the EFI pagetable" 67 depends on EFI 68 select PTDUMP_CORE 69 ---help--- 70 Enable this if you want to dump the EFI page table before 71 enabling virtual mode. This can be used to debug miscellaneous 72 issues with the mapping of the EFI runtime regions into that 73 table. 74 75config DEBUG_WX 76 bool "Warn on W+X mappings at boot" 77 select PTDUMP_CORE 78 ---help--- 79 Generate a warning if any W+X mappings are found at boot. 80 81 This is useful for discovering cases where the kernel is leaving 82 W+X mappings after applying NX, as such mappings are a security risk. 83 84 Look for a message in dmesg output like this: 85 86 x86/mm: Checked W+X mappings: passed, no W+X pages found. 87 88 or like this, if the check failed: 89 90 x86/mm: Checked W+X mappings: FAILED, <N> W+X pages found. 91 92 Note that even if the check fails, your kernel is possibly 93 still fine, as W+X mappings are not a security hole in 94 themselves, what they do is that they make the exploitation 95 of other unfixed kernel bugs easier. 96 97 There is no runtime or memory usage effect of this option 98 once the kernel has booted up - it's a one time check. 99 100 If in doubt, say "Y". 101 102config DEBUG_TLBFLUSH 103 bool "Set upper limit of TLB entries to flush one-by-one" 104 depends on DEBUG_KERNEL 105 ---help--- 106 107 X86-only for now. 108 109 This option allows the user to tune the amount of TLB entries the 110 kernel flushes one-by-one instead of doing a full TLB flush. In 111 certain situations, the former is cheaper. This is controlled by the 112 tlb_flushall_shift knob under /sys/kernel/debug/x86. If you set it 113 to -1, the code flushes the whole TLB unconditionally. Otherwise, 114 for positive values of it, the kernel will use single TLB entry 115 invalidating instructions according to the following formula: 116 117 flush_entries <= active_tlb_entries / 2^tlb_flushall_shift 118 119 If in doubt, say "N". 120 121config IOMMU_DEBUG 122 bool "Enable IOMMU debugging" 123 depends on GART_IOMMU && DEBUG_KERNEL 124 depends on X86_64 125 ---help--- 126 Force the IOMMU to on even when you have less than 4GB of 127 memory and add debugging code. On overflow always panic. And 128 allow to enable IOMMU leak tracing. Can be disabled at boot 129 time with iommu=noforce. This will also enable scatter gather 130 list merging. Currently not recommended for production 131 code. When you use it make sure you have a big enough 132 IOMMU/AGP aperture. Most of the options enabled by this can 133 be set more finegrained using the iommu= command line 134 options. See Documentation/x86/x86_64/boot-options.rst for more 135 details. 136 137config IOMMU_LEAK 138 bool "IOMMU leak tracing" 139 depends on IOMMU_DEBUG && DMA_API_DEBUG 140 ---help--- 141 Add a simple leak tracer to the IOMMU code. This is useful when you 142 are debugging a buggy device driver that leaks IOMMU mappings. 143 144config HAVE_MMIOTRACE_SUPPORT 145 def_bool y 146 147config X86_DECODER_SELFTEST 148 bool "x86 instruction decoder selftest" 149 depends on DEBUG_KERNEL && INSTRUCTION_DECODER 150 depends on !COMPILE_TEST 151 ---help--- 152 Perform x86 instruction decoder selftests at build time. 153 This option is useful for checking the sanity of x86 instruction 154 decoder code. 155 If unsure, say "N". 156 157choice 158 prompt "IO delay type" 159 default IO_DELAY_0X80 160 161config IO_DELAY_0X80 162 bool "port 0x80 based port-IO delay [recommended]" 163 ---help--- 164 This is the traditional Linux IO delay used for in/out_p. 165 It is the most tested hence safest selection here. 166 167config IO_DELAY_0XED 168 bool "port 0xed based port-IO delay" 169 ---help--- 170 Use port 0xed as the IO delay. This frees up port 0x80 which is 171 often used as a hardware-debug port. 172 173config IO_DELAY_UDELAY 174 bool "udelay based port-IO delay" 175 ---help--- 176 Use udelay(2) as the IO delay method. This provides the delay 177 while not having any side-effect on the IO port space. 178 179config IO_DELAY_NONE 180 bool "no port-IO delay" 181 ---help--- 182 No port-IO delay. Will break on old boxes that require port-IO 183 delay for certain operations. Should work on most new machines. 184 185endchoice 186 187config DEBUG_BOOT_PARAMS 188 bool "Debug boot parameters" 189 depends on DEBUG_KERNEL 190 depends on DEBUG_FS 191 ---help--- 192 This option will cause struct boot_params to be exported via debugfs. 193 194config CPA_DEBUG 195 bool "CPA self-test code" 196 depends on DEBUG_KERNEL 197 ---help--- 198 Do change_page_attr() self-tests every 30 seconds. 199 200config DEBUG_ENTRY 201 bool "Debug low-level entry code" 202 depends on DEBUG_KERNEL 203 ---help--- 204 This option enables sanity checks in x86's low-level entry code. 205 Some of these sanity checks may slow down kernel entries and 206 exits or otherwise impact performance. 207 208 If unsure, say N. 209 210config DEBUG_NMI_SELFTEST 211 bool "NMI Selftest" 212 depends on DEBUG_KERNEL && X86_LOCAL_APIC 213 ---help--- 214 Enabling this option turns on a quick NMI selftest to verify 215 that the NMI behaves correctly. 216 217 This might help diagnose strange hangs that rely on NMI to 218 function properly. 219 220 If unsure, say N. 221 222config DEBUG_IMR_SELFTEST 223 bool "Isolated Memory Region self test" 224 depends on INTEL_IMR 225 ---help--- 226 This option enables automated sanity testing of the IMR code. 227 Some simple tests are run to verify IMR bounds checking, alignment 228 and overlapping. This option is really only useful if you are 229 debugging an IMR memory map or are modifying the IMR code and want to 230 test your changes. 231 232 If unsure say N here. 233 234config X86_DEBUG_FPU 235 bool "Debug the x86 FPU code" 236 depends on DEBUG_KERNEL 237 default y 238 ---help--- 239 If this option is enabled then there will be extra sanity 240 checks and (boot time) debug printouts added to the kernel. 241 This debugging adds some small amount of runtime overhead 242 to the kernel. 243 244 If unsure, say N. 245 246config PUNIT_ATOM_DEBUG 247 tristate "ATOM Punit debug driver" 248 depends on PCI 249 select DEBUG_FS 250 select IOSF_MBI 251 ---help--- 252 This is a debug driver, which gets the power states 253 of all Punit North Complex devices. The power states of 254 each device is exposed as part of the debugfs interface. 255 The current power state can be read from 256 /sys/kernel/debug/punit_atom/dev_power_state 257 258choice 259 prompt "Choose kernel unwinder" 260 default UNWINDER_ORC if X86_64 261 default UNWINDER_FRAME_POINTER if X86_32 262 ---help--- 263 This determines which method will be used for unwinding kernel stack 264 traces for panics, oopses, bugs, warnings, perf, /proc/<pid>/stack, 265 livepatch, lockdep, and more. 266 267config UNWINDER_ORC 268 bool "ORC unwinder" 269 depends on X86_64 270 select STACK_VALIDATION 271 ---help--- 272 This option enables the ORC (Oops Rewind Capability) unwinder for 273 unwinding kernel stack traces. It uses a custom data format which is 274 a simplified version of the DWARF Call Frame Information standard. 275 276 This unwinder is more accurate across interrupt entry frames than the 277 frame pointer unwinder. It also enables a 5-10% performance 278 improvement across the entire kernel compared to frame pointers. 279 280 Enabling this option will increase the kernel's runtime memory usage 281 by roughly 2-4MB, depending on your kernel config. 282 283config UNWINDER_FRAME_POINTER 284 bool "Frame pointer unwinder" 285 select FRAME_POINTER 286 ---help--- 287 This option enables the frame pointer unwinder for unwinding kernel 288 stack traces. 289 290 The unwinder itself is fast and it uses less RAM than the ORC 291 unwinder, but the kernel text size will grow by ~3% and the kernel's 292 overall performance will degrade by roughly 5-10%. 293 294config UNWINDER_GUESS 295 bool "Guess unwinder" 296 depends on EXPERT 297 depends on !STACKDEPOT 298 ---help--- 299 This option enables the "guess" unwinder for unwinding kernel stack 300 traces. It scans the stack and reports every kernel text address it 301 finds. Some of the addresses it reports may be incorrect. 302 303 While this option often produces false positives, it can still be 304 useful in many cases. Unlike the other unwinders, it has no runtime 305 overhead. 306 307endchoice 308 309config FRAME_POINTER 310 depends on !UNWINDER_ORC && !UNWINDER_GUESS 311 bool 312