341 lines
11 KiB
Plaintext
341 lines
11 KiB
Plaintext
|
# 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_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.rst 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".
|
||
|
|
|
||
|
|
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
|
||
|
|
|
||
|
|
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 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"
|
||
|
|
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
|