# SPDX-License-Identifier: GPL-2.0 
 | 
  
 | 
config TRACE_IRQFLAGS_SUPPORT 
 | 
    def_bool y 
 | 
  
 | 
config EARLY_PRINTK_USB 
 | 
    bool 
 | 
  
 | 
config X86_VERBOSE_BOOTUP 
 | 
    bool "Enable verbose x86 bootup info messages" 
 | 
    default y 
 | 
    ---help--- 
 | 
      Enables the informational output from the decompression stage 
 | 
      (e.g. bzImage) of the boot. If you disable this you will still 
 | 
      see errors. Disable this if you want silent bootup. 
 | 
  
 | 
config EARLY_PRINTK 
 | 
    bool "Early printk" if EXPERT 
 | 
    default y 
 | 
    ---help--- 
 | 
      Write kernel log output directly into the VGA buffer or to a serial 
 | 
      port. 
 | 
  
 | 
      This is useful for kernel debugging when your machine crashes very 
 | 
      early before the console code is initialized. For normal operation 
 | 
      it is not recommended because it looks ugly and doesn't cooperate 
 | 
      with klogd/syslogd or the X server. You should normally say N here, 
 | 
      unless you want to debug such a crash. 
 | 
  
 | 
config EARLY_PRINTK_DBGP 
 | 
    bool "Early printk via EHCI debug port" 
 | 
    depends on EARLY_PRINTK && PCI 
 | 
    select EARLY_PRINTK_USB 
 | 
    ---help--- 
 | 
      Write kernel log output directly into the EHCI debug port. 
 | 
  
 | 
      This is useful for kernel debugging when your machine crashes very 
 | 
      early before the console code is initialized. For normal operation 
 | 
      it is not recommended because it looks ugly and doesn't cooperate 
 | 
      with klogd/syslogd or the X server. You should normally say N here, 
 | 
      unless you want to debug such a crash. You need usb debug device. 
 | 
  
 | 
config EARLY_PRINTK_EFI 
 | 
    bool "Early printk via the EFI framebuffer" 
 | 
    depends on EFI && EARLY_PRINTK 
 | 
    select FONT_SUPPORT 
 | 
    ---help--- 
 | 
      Write kernel log output directly into the EFI framebuffer. 
 | 
  
 | 
      This is useful for kernel debugging when your machine crashes very 
 | 
      early before the console code is initialized. 
 | 
  
 | 
config EARLY_PRINTK_USB_XDBC 
 | 
    bool "Early printk via the xHCI debug port" 
 | 
    depends on EARLY_PRINTK && PCI 
 | 
    select EARLY_PRINTK_USB 
 | 
    ---help--- 
 | 
      Write kernel log output directly into the xHCI debug port. 
 | 
  
 | 
      One use for this feature is kernel debugging, for example when your 
 | 
      machine crashes very early before the regular console code is 
 | 
      initialized. Other uses include simpler, lockless logging instead of 
 | 
      a full-blown printk console driver + klogd. 
 | 
  
 | 
      For normal production environments this is normally not recommended, 
 | 
      because it doesn't feed events into klogd/syslogd and doesn't try to 
 | 
      print anything on the screen. 
 | 
  
 | 
      You should normally say N here, unless you want to debug early 
 | 
      crashes or need a very simple printk logging facility. 
 | 
  
 | 
config MCSAFE_TEST 
 | 
    def_bool n 
 | 
  
 | 
config X86_PTDUMP_CORE 
 | 
    def_bool n 
 | 
  
 | 
config X86_PTDUMP 
 | 
    tristate "Export kernel pagetable layout to userspace via debugfs" 
 | 
    depends on DEBUG_KERNEL 
 | 
    select DEBUG_FS 
 | 
    select X86_PTDUMP_CORE 
 | 
    ---help--- 
 | 
      Say Y here if you want to show the kernel pagetable layout in a 
 | 
      debugfs file. This information is only useful for kernel developers 
 | 
      who are working in architecture specific areas of the kernel. 
 | 
      It is probably not a good idea to enable this feature in a production 
 | 
      kernel. 
 | 
      If in doubt, say "N" 
 | 
  
 | 
config EFI_PGT_DUMP 
 | 
    bool "Dump the EFI pagetable" 
 | 
    depends on EFI 
 | 
    select X86_PTDUMP_CORE 
 | 
    ---help--- 
 | 
      Enable this if you want to dump the EFI page table before 
 | 
      enabling virtual mode. This can be used to debug miscellaneous 
 | 
      issues with the mapping of the EFI runtime regions into that 
 | 
      table. 
 | 
  
 | 
config DEBUG_WX 
 | 
    bool "Warn on W+X mappings at boot" 
 | 
    select X86_PTDUMP_CORE 
 | 
    ---help--- 
 | 
      Generate a warning if any W+X mappings are found at boot. 
 | 
  
 | 
      This is useful for discovering cases where the kernel is leaving 
 | 
      W+X mappings after applying NX, as such mappings are a security risk. 
 | 
  
 | 
      Look for a message in dmesg output like this: 
 | 
  
 | 
        x86/mm: Checked W+X mappings: passed, no W+X pages found. 
 | 
  
 | 
      or like this, if the check failed: 
 | 
  
 | 
        x86/mm: Checked W+X mappings: FAILED, <N> W+X pages found. 
 | 
  
 | 
      Note that even if the check fails, your kernel is possibly 
 | 
      still fine, as W+X mappings are not a security hole in 
 | 
      themselves, what they do is that they make the exploitation 
 | 
      of other unfixed kernel bugs easier. 
 | 
  
 | 
      There is no runtime or memory usage effect of this option 
 | 
      once the kernel has booted up - it's a one time check. 
 | 
  
 | 
      If in doubt, say "Y". 
 | 
  
 | 
config DOUBLEFAULT 
 | 
    default y 
 | 
    bool "Enable doublefault exception handler" if EXPERT 
 | 
    ---help--- 
 | 
      This option allows trapping of rare doublefault exceptions that 
 | 
      would otherwise cause a system to silently reboot. Disabling this 
 | 
      option saves about 4k and might cause you much additional grey 
 | 
      hair. 
 | 
  
 | 
config DEBUG_TLBFLUSH 
 | 
    bool "Set upper limit of TLB entries to flush one-by-one" 
 | 
    depends on DEBUG_KERNEL 
 | 
    ---help--- 
 | 
  
 | 
    X86-only for now. 
 | 
  
 | 
    This option allows the user to tune the amount of TLB entries the 
 | 
    kernel flushes one-by-one instead of doing a full TLB flush. In 
 | 
    certain situations, the former is cheaper. This is controlled by the 
 | 
    tlb_flushall_shift knob under /sys/kernel/debug/x86. If you set it 
 | 
    to -1, the code flushes the whole TLB unconditionally. Otherwise, 
 | 
    for positive values of it, the kernel will use single TLB entry 
 | 
    invalidating instructions according to the following formula: 
 | 
  
 | 
    flush_entries <= active_tlb_entries / 2^tlb_flushall_shift 
 | 
  
 | 
    If in doubt, say "N". 
 | 
  
 | 
config IOMMU_DEBUG 
 | 
    bool "Enable IOMMU debugging" 
 | 
    depends on GART_IOMMU && DEBUG_KERNEL 
 | 
    depends on X86_64 
 | 
    ---help--- 
 | 
      Force the IOMMU to on even when you have less than 4GB of 
 | 
      memory and add debugging code. On overflow always panic. And 
 | 
      allow to enable IOMMU leak tracing. Can be disabled at boot 
 | 
      time with iommu=noforce. This will also enable scatter gather 
 | 
      list merging.  Currently not recommended for production 
 | 
      code. When you use it make sure you have a big enough 
 | 
      IOMMU/AGP aperture.  Most of the options enabled by this can 
 | 
      be set more finegrained using the iommu= command line 
 | 
      options. See Documentation/x86/x86_64/boot-options.txt for more 
 | 
      details. 
 | 
  
 | 
config IOMMU_LEAK 
 | 
    bool "IOMMU leak tracing" 
 | 
    depends on IOMMU_DEBUG && DMA_API_DEBUG 
 | 
    ---help--- 
 | 
      Add a simple leak tracer to the IOMMU code. This is useful when you 
 | 
      are debugging a buggy device driver that leaks IOMMU mappings. 
 | 
  
 | 
config HAVE_MMIOTRACE_SUPPORT 
 | 
    def_bool y 
 | 
  
 | 
config X86_DECODER_SELFTEST 
 | 
    bool "x86 instruction decoder selftest" 
 | 
    depends on DEBUG_KERNEL && INSTRUCTION_DECODER 
 | 
    depends on !COMPILE_TEST 
 | 
    ---help--- 
 | 
     Perform x86 instruction decoder selftests at build time. 
 | 
     This option is useful for checking the sanity of x86 instruction 
 | 
     decoder code. 
 | 
     If unsure, say "N". 
 | 
  
 | 
# 
 | 
# IO delay types: 
 | 
# 
 | 
  
 | 
config IO_DELAY_TYPE_0X80 
 | 
    int 
 | 
    default "0" 
 | 
  
 | 
config IO_DELAY_TYPE_0XED 
 | 
    int 
 | 
    default "1" 
 | 
  
 | 
config IO_DELAY_TYPE_UDELAY 
 | 
    int 
 | 
    default "2" 
 | 
  
 | 
config IO_DELAY_TYPE_NONE 
 | 
    int 
 | 
    default "3" 
 | 
  
 | 
choice 
 | 
    prompt "IO delay type" 
 | 
    default IO_DELAY_0X80 
 | 
  
 | 
config IO_DELAY_0X80 
 | 
    bool "port 0x80 based port-IO delay [recommended]" 
 | 
    ---help--- 
 | 
      This is the traditional Linux IO delay used for in/out_p. 
 | 
      It is the most tested hence safest selection here. 
 | 
  
 | 
config IO_DELAY_0XED 
 | 
    bool "port 0xed based port-IO delay" 
 | 
    ---help--- 
 | 
      Use port 0xed as the IO delay. This frees up port 0x80 which is 
 | 
      often used as a hardware-debug port. 
 | 
  
 | 
config IO_DELAY_UDELAY 
 | 
    bool "udelay based port-IO delay" 
 | 
    ---help--- 
 | 
      Use udelay(2) as the IO delay method. This provides the delay 
 | 
      while not having any side-effect on the IO port space. 
 | 
  
 | 
config IO_DELAY_NONE 
 | 
    bool "no port-IO delay" 
 | 
    ---help--- 
 | 
      No port-IO delay. Will break on old boxes that require port-IO 
 | 
      delay for certain operations. Should work on most new machines. 
 | 
  
 | 
endchoice 
 | 
  
 | 
if IO_DELAY_0X80 
 | 
config DEFAULT_IO_DELAY_TYPE 
 | 
    int 
 | 
    default IO_DELAY_TYPE_0X80 
 | 
endif 
 | 
  
 | 
if IO_DELAY_0XED 
 | 
config DEFAULT_IO_DELAY_TYPE 
 | 
    int 
 | 
    default IO_DELAY_TYPE_0XED 
 | 
endif 
 | 
  
 | 
if IO_DELAY_UDELAY 
 | 
config DEFAULT_IO_DELAY_TYPE 
 | 
    int 
 | 
    default IO_DELAY_TYPE_UDELAY 
 | 
endif 
 | 
  
 | 
if IO_DELAY_NONE 
 | 
config DEFAULT_IO_DELAY_TYPE 
 | 
    int 
 | 
    default IO_DELAY_TYPE_NONE 
 | 
endif 
 | 
  
 | 
config DEBUG_BOOT_PARAMS 
 | 
    bool "Debug boot parameters" 
 | 
    depends on DEBUG_KERNEL 
 | 
    depends on DEBUG_FS 
 | 
    ---help--- 
 | 
      This option will cause struct boot_params to be exported via debugfs. 
 | 
  
 | 
config CPA_DEBUG 
 | 
    bool "CPA self-test code" 
 | 
    depends on DEBUG_KERNEL 
 | 
    ---help--- 
 | 
      Do change_page_attr() self-tests every 30 seconds. 
 | 
  
 | 
config OPTIMIZE_INLINING 
 | 
    bool "Allow gcc to uninline functions marked 'inline'" 
 | 
    ---help--- 
 | 
      This option determines if the kernel forces gcc to inline the functions 
 | 
      developers have marked 'inline'. Doing so takes away freedom from gcc to 
 | 
      do what it thinks is best, which is desirable for the gcc 3.x series of 
 | 
      compilers. The gcc 4.x series have a rewritten inlining algorithm and 
 | 
      enabling this option will generate a smaller kernel there. Hopefully 
 | 
      this algorithm is so good that allowing gcc 4.x and above to make the 
 | 
      decision will become the default in the future. Until then this option 
 | 
      is there to test gcc for this. 
 | 
  
 | 
      If unsure, say N. 
 | 
  
 | 
config DEBUG_ENTRY 
 | 
    bool "Debug low-level entry code" 
 | 
    depends on DEBUG_KERNEL 
 | 
    ---help--- 
 | 
      This option enables sanity checks in x86's low-level entry code. 
 | 
      Some of these sanity checks may slow down kernel entries and 
 | 
      exits or otherwise impact performance. 
 | 
  
 | 
      If unsure, say N. 
 | 
  
 | 
config DEBUG_NMI_SELFTEST 
 | 
    bool "NMI Selftest" 
 | 
    depends on DEBUG_KERNEL && X86_LOCAL_APIC 
 | 
    ---help--- 
 | 
      Enabling this option turns on a quick NMI selftest to verify 
 | 
      that the NMI behaves correctly. 
 | 
  
 | 
      This might help diagnose strange hangs that rely on NMI to 
 | 
      function properly. 
 | 
  
 | 
      If unsure, say N. 
 | 
  
 | 
config DEBUG_IMR_SELFTEST 
 | 
    bool "Isolated Memory Region self test" 
 | 
    default n 
 | 
    depends on INTEL_IMR 
 | 
    ---help--- 
 | 
      This option enables automated sanity testing of the IMR code. 
 | 
      Some simple tests are run to verify IMR bounds checking, alignment 
 | 
      and overlapping. This option is really only useful if you are 
 | 
      debugging an IMR memory map or are modifying the IMR code and want to 
 | 
      test your changes. 
 | 
  
 | 
      If unsure say N here. 
 | 
  
 | 
config X86_DEBUG_FPU 
 | 
    bool "Debug the x86 FPU code" 
 | 
    depends on DEBUG_KERNEL 
 | 
    default y 
 | 
    ---help--- 
 | 
      If this option is enabled then there will be extra sanity 
 | 
      checks and (boot time) debug printouts added to the kernel. 
 | 
      This debugging adds some small amount of runtime overhead 
 | 
      to the kernel. 
 | 
  
 | 
      If unsure, say N. 
 | 
  
 | 
config PUNIT_ATOM_DEBUG 
 | 
    tristate "ATOM Punit debug driver" 
 | 
    depends on PCI 
 | 
    select DEBUG_FS 
 | 
    select IOSF_MBI 
 | 
    ---help--- 
 | 
      This is a debug driver, which gets the power states 
 | 
      of all Punit North Complex devices. The power states of 
 | 
      each device is exposed as part of the debugfs interface. 
 | 
      The current power state can be read from 
 | 
      /sys/kernel/debug/punit_atom/dev_power_state 
 | 
  
 | 
choice 
 | 
    prompt "Choose kernel unwinder" 
 | 
    default UNWINDER_ORC if X86_64 
 | 
    default UNWINDER_FRAME_POINTER if X86_32 
 | 
    ---help--- 
 | 
      This determines which method will be used for unwinding kernel stack 
 | 
      traces for panics, oopses, bugs, warnings, perf, /proc/<pid>/stack, 
 | 
      livepatch, lockdep, and more. 
 | 
  
 | 
config UNWINDER_ORC 
 | 
    bool "ORC unwinder" 
 | 
    depends on X86_64 
 | 
    select STACK_VALIDATION 
 | 
    ---help--- 
 | 
      This option enables the ORC (Oops Rewind Capability) unwinder for 
 | 
      unwinding kernel stack traces.  It uses a custom data format which is 
 | 
      a simplified version of the DWARF Call Frame Information standard. 
 | 
  
 | 
      This unwinder is more accurate across interrupt entry frames than the 
 | 
      frame pointer unwinder.  It also enables a 5-10% performance 
 | 
      improvement across the entire kernel compared to frame pointers. 
 | 
  
 | 
      Enabling this option will increase the kernel's runtime memory usage 
 | 
      by roughly 2-4MB, depending on your kernel config. 
 | 
  
 | 
config UNWINDER_FRAME_POINTER 
 | 
    bool "Frame pointer unwinder" 
 | 
    select FRAME_POINTER 
 | 
    ---help--- 
 | 
      This option enables the frame pointer unwinder for unwinding kernel 
 | 
      stack traces. 
 | 
  
 | 
      The unwinder itself is fast and it uses less RAM than the ORC 
 | 
      unwinder, but the kernel text size will grow by ~3% and the kernel's 
 | 
      overall performance will degrade by roughly 5-10%. 
 | 
  
 | 
      This option is recommended if you want to use the livepatch 
 | 
      consistency model, as this is currently the only way to get a 
 | 
      reliable stack trace (CONFIG_HAVE_RELIABLE_STACKTRACE). 
 | 
  
 | 
config UNWINDER_GUESS 
 | 
    bool "Guess unwinder" 
 | 
    depends on EXPERT 
 | 
    depends on !STACKDEPOT 
 | 
    ---help--- 
 | 
      This option enables the "guess" unwinder for unwinding kernel stack 
 | 
      traces.  It scans the stack and reports every kernel text address it 
 | 
      finds.  Some of the addresses it reports may be incorrect. 
 | 
  
 | 
      While this option often produces false positives, it can still be 
 | 
      useful in many cases.  Unlike the other unwinders, it has no runtime 
 | 
      overhead. 
 | 
  
 | 
endchoice 
 | 
  
 | 
config FRAME_POINTER 
 | 
    depends on !UNWINDER_ORC && !UNWINDER_GUESS 
 | 
    bool 
 |