2 # For a description of the syntax of this configuration file,
3 # see Documentation/kbuild/kconfig-language.txt.
5 # Note: ISA is disabled and will hopefully never be enabled.
6 # If you managed to buy an ISA x86-64 box you'll have to fix all the
7 # ISA drivers you need yourself.
10 mainmenu "Linux Kernel Configuration"
16 Port to the x86-64 architecture. x86-64 is a 64-bit extension to the
17 classical 32-bit x86 architecture. For details see
18 <http://www.x86-64.org/>.
31 config GENERIC_TIME_VSYSCALL
35 config GENERIC_CMOS_UPDATE
39 config CLOCKSOURCE_WATCHDOG
43 config GENERIC_CLOCKEVENTS
47 config GENERIC_CLOCKEVENTS_BROADCAST
55 config LOCKDEP_SUPPORT
59 config STACKTRACE_SUPPORT
63 config SEMAPHORE_SLEEPERS
81 config RWSEM_GENERIC_SPINLOCK
85 config RWSEM_XCHGADD_ALGORITHM
88 config GENERIC_HWEIGHT
92 config GENERIC_CALIBRATE_DELAY
100 config GENERIC_ISA_DMA
108 config ARCH_MAY_HAVE_PC_FDC
112 config ARCH_POPULATES_NODE_MAP
128 config ARCH_HAS_ILOG2_U32
132 config ARCH_HAS_ILOG2_U64
136 source "init/Kconfig"
139 menu "Processor type and features"
141 source "kernel/time/Kconfig"
144 prompt "Subarchitecture Type"
150 Choose this option if your computer is a standard PC or compatible.
153 bool "Support for ScaleMP vSMP"
156 Support for ScaleMP vSMP systems. Say 'Y' here if this kernel is
157 supposed to run on these EM64T-based machines. Only choose this option
158 if you have one of these machines.
163 prompt "Processor family"
167 bool "AMD-Opteron/Athlon64"
169 Optimize for AMD Opteron/Athlon64/Hammer/K8 CPUs.
172 bool "Intel P4 / older Netburst based Xeon"
174 Optimize for Intel Pentium 4, Pentium D and older Nocona/Dempsey
175 Xeon CPUs with Intel 64bit which is compatible with x86-64.
176 Note that the latest Xeons (Xeon 51xx and 53xx) are not based on the
177 Netburst core and shouldn't use this option. You can distinguish them
178 using the cpu family field
179 in /proc/cpuinfo. Family 15 is an older Xeon, Family 6 a newer one.
182 bool "Intel Core2 / newer Xeon"
184 Optimize for Intel Core2 and newer Xeons (51xx)
185 You can distinguish the newer Xeons from the older ones using
186 the cpu family field in /proc/cpuinfo. 15 is an older Xeon
187 (use CONFIG_MPSC then), 6 is a newer one.
190 bool "Generic-x86-64"
193 Run equally well on all x86-64 CPUs.
198 # Define implied options from the CPU selection here
200 config X86_L1_CACHE_BYTES
202 default "128" if GENERIC_CPU || MPSC
203 default "64" if MK8 || MCORE2
205 config X86_L1_CACHE_SHIFT
207 default "7" if GENERIC_CPU || MPSC
208 default "6" if MK8 || MCORE2
210 config X86_INTERNODE_CACHE_BYTES
212 default "4096" if X86_VSMP
213 default X86_L1_CACHE_BYTES if !X86_VSMP
224 tristate "/dev/cpu/microcode - Intel CPU microcode support"
227 If you say Y here the 'File systems' section, you will be
228 able to update the microcode on Intel processors. You will
229 obviously need the actual microcode binary data itself which is
230 not shipped with the Linux kernel.
232 For latest news and information on obtaining all the required
233 ingredients for this driver, check:
234 <http://www.urbanmyth.org/microcode/>.
236 To compile this driver as a module, choose M here: the
237 module will be called microcode.
238 If you use modprobe or kmod you may also want to add the line
239 'alias char-major-10-184 microcode' to your /etc/modules.conf file.
241 config MICROCODE_OLD_INTERFACE
247 tristate "/dev/cpu/*/msr - Model-specific register support"
249 This device gives privileged processes access to the x86
250 Model-Specific Registers (MSRs). It is a character device with
251 major 202 and minors 0 to 31 for /dev/cpu/0/msr to /dev/cpu/31/msr.
252 MSR accesses are directed to a specific CPU on multi-processor
256 tristate "/dev/cpu/*/cpuid - CPU information support"
258 This device gives processes access to the x86 CPUID instruction to
259 be executed on a specific processor. It is a character device
260 with major 203 and minors 0 to 31 for /dev/cpu/0/cpuid to
265 depends on SMP && !MK8
268 config MATH_EMULATION
281 config X86_LOCAL_APIC
286 bool "MTRR (Memory Type Range Register) support"
288 On Intel P6 family processors (Pentium Pro, Pentium II and later)
289 the Memory Type Range Registers (MTRRs) may be used to control
290 processor access to memory ranges. This is most useful if you have
291 a video (VGA) card on a PCI or AGP bus. Enabling write-combining
292 allows bus write transfers to be combined into a larger transfer
293 before bursting over the PCI/AGP bus. This can increase performance
294 of image write operations 2.5 times or more. Saying Y here creates a
295 /proc/mtrr file which may be used to manipulate your processor's
296 MTRRs. Typically the X server should use this.
298 This code has a reasonably generic interface so that similar
299 control registers on other processors can be easily supported
302 Saying Y here also fixes a problem with buggy SMP BIOSes which only
303 set the MTRRs for the boot CPU and not for the secondary CPUs. This
304 can lead to all sorts of problems, so it's good to say Y here.
306 Just say Y here, all x86-64 machines support MTRRs.
308 See <file:Documentation/mtrr.txt> for more information.
311 bool "Symmetric multi-processing support"
313 This enables support for systems with more than one CPU. If you have
314 a system with only one CPU, like most personal computers, say N. If
315 you have a system with more than one CPU, say Y.
317 If you say N here, the kernel will run on single and multiprocessor
318 machines, but will use only one CPU of a multiprocessor machine. If
319 you say Y here, the kernel will run on many, but not all,
320 singleprocessor machines. On a singleprocessor machine, the kernel
321 will run faster if you say N here.
323 If you don't know what to do here, say N.
326 bool "SMT (Hyperthreading) scheduler support"
330 SMT scheduler support improves the CPU scheduler's decision making
331 when dealing with Intel Pentium 4 chips with HyperThreading at a
332 cost of slightly increased overhead in some places. If unsure say
336 bool "Multi-core scheduler support"
340 Multi-core scheduler support improves the CPU scheduler's decision
341 making when dealing with multi-core CPU chips at a cost of slightly
342 increased overhead in some places. If unsure say N here.
344 source "kernel/Kconfig.preempt"
347 bool "Non Uniform Memory Access (NUMA) Support"
350 Enable NUMA (Non Uniform Memory Access) support. The kernel
351 will try to allocate memory used by a CPU on the local memory
352 controller of the CPU and add some more NUMA awareness to the kernel.
353 This code is recommended on all multiprocessor Opteron systems.
354 If the system is EM64T, you should say N unless your system is EM64T
358 bool "Old style AMD Opteron NUMA detection"
359 depends on NUMA && PCI
362 Enable K8 NUMA node topology detection. You should say Y here if
363 you have a multi processor AMD K8 system. This uses an old
364 method to read the NUMA configuration directly from the builtin
365 Northbridge of Opteron. It is recommended to use X86_64_ACPI_NUMA
366 instead, which also takes priority if both are compiled in.
371 depends on NEED_MULTIPLE_NODES
373 # Dummy CONFIG option to select ACPI_NUMA from drivers/acpi/Kconfig.
375 config X86_64_ACPI_NUMA
376 bool "ACPI NUMA detection"
383 Enable ACPI SRAT based node topology detection.
386 bool "NUMA emulation"
389 Enable NUMA emulation. A flat machine will be split
390 into virtual nodes when booted with "numa=fake=N", where N is the
391 number of nodes. This is only useful for debugging.
393 config ARCH_DISCONTIGMEM_ENABLE
398 config ARCH_DISCONTIGMEM_DEFAULT
402 config ARCH_SPARSEMEM_ENABLE
404 depends on (NUMA || EXPERIMENTAL)
405 select SPARSEMEM_VMEMMAP_ENABLE
407 config ARCH_MEMORY_PROBE
409 depends on MEMORY_HOTPLUG
411 config ARCH_FLATMEM_ENABLE
417 config MEMORY_HOTPLUG_RESERVE
419 depends on (MEMORY_HOTPLUG && DISCONTIGMEM)
421 config HAVE_ARCH_EARLY_PFN_TO_NID
425 config OUT_OF_LINE_PFN_TO_PAGE
427 depends on DISCONTIGMEM
430 int "Maximum number of CPUs (2-255)"
435 This allows you to specify the maximum number of CPUs which this
436 kernel will support. Current maximum is 255 CPUs due to
437 APIC addressing limits. Less depending on the hardware.
439 This is purely to save memory - each supported CPU requires
440 memory in the static kernel configuration.
442 config PHYSICAL_ALIGN
447 bool "Support for suspend on SMP and hot-pluggable CPUs (EXPERIMENTAL)"
448 depends on SMP && HOTPLUG && EXPERIMENTAL
450 Say Y here to experiment with turning CPUs off and on. CPUs
451 can be controlled through /sys/devices/system/cpu/cpu#.
452 This is also required for suspend/hibernation on SMP systems.
454 Say N if you want to disable CPU hotplug and don't need to
457 config ARCH_ENABLE_MEMORY_HOTPLUG
464 Use the IA-PC HPET (High Precision Event Timer) to manage
465 time in preference to the PIT and RTC, if a HPET is
466 present. The HPET provides a stable time base on SMP
467 systems, unlike the TSC, but it is more expensive to access,
468 as it is off-chip. You can find the HPET spec at
469 <http://www.intel.com/hardwaredesign/hpetspec.htm>.
471 config HPET_EMULATE_RTC
473 depends on HPET_TIMER && RTC=y
476 # Mark as embedded because too many people got it wrong.
477 # The code disables itself when not needed.
479 bool "GART IOMMU support" if EMBEDDED
485 Support for full DMA access of devices with 32bit memory access only
486 on systems with more than 3GB. This is usually needed for USB,
487 sound, many IDE/SATA chipsets and some other devices.
488 Provides a driver for the AMD Athlon64/Opteron/Turion/Sempron GART
489 based hardware IOMMU and a software bounce buffer based IOMMU used
490 on Intel systems and as fallback.
491 The code is only active when needed (enough memory and limited
492 device) unless CONFIG_IOMMU_DEBUG or iommu=force is specified
496 bool "IBM Calgary IOMMU support"
498 depends on PCI && EXPERIMENTAL
500 Support for hardware IOMMUs in IBM's xSeries x366 and x460
501 systems. Needed to run systems with more than 3GB of memory
502 properly with 32-bit PCI devices that do not support DAC
503 (Double Address Cycle). Calgary also supports bus level
504 isolation, where all DMAs pass through the IOMMU. This
505 prevents them from going anywhere except their intended
506 destination. This catches hard-to-find kernel bugs and
507 mis-behaving drivers and devices that do not use the DMA-API
508 properly to set up their DMA buffers. The IOMMU can be
509 turned off at boot time with the iommu=off parameter.
510 Normally the kernel will make the right choice by itself.
513 config CALGARY_IOMMU_ENABLED_BY_DEFAULT
514 bool "Should Calgary be enabled by default?"
516 depends on CALGARY_IOMMU
518 Should Calgary be enabled by default? if you choose 'y', Calgary
519 will be used (if it exists). If you choose 'n', Calgary will not be
520 used even if it exists. If you choose 'n' and would like to use
521 Calgary anyway, pass 'iommu=calgary' on the kernel command line.
524 # need this always selected by IOMMU for the VIA workaround
528 Support for software bounce buffers used on x86-64 systems
529 which don't have a hardware IOMMU (e.g. the current generation
530 of Intel's x86-64 CPUs). Using this PCI devices which can only
531 access 32-bits of memory can be used on systems with more than
532 3 GB of memory. If unsure, say Y.
535 bool "Machine check support" if EMBEDDED
538 Include a machine check error handler to report hardware errors.
539 This version will require the mcelog utility to decode some
540 machine check error logs. See
541 ftp://ftp.x86-64.org/pub/linux/tools/mcelog
544 bool "Intel MCE features"
545 depends on X86_MCE && X86_LOCAL_APIC
548 Additional support for intel specific MCE features such as
552 bool "AMD MCE features"
553 depends on X86_MCE && X86_LOCAL_APIC
556 Additional support for AMD specific MCE features such as
557 the DRAM Error Threshold.
560 bool "kexec system call"
562 kexec is a system call that implements the ability to shutdown your
563 current kernel, and to start another kernel. It is like a reboot
564 but it is independent of the system firmware. And like a reboot
565 you can start any kernel with it, not just Linux.
567 The name comes from the similarity to the exec system call.
569 It is an ongoing process to be certain the hardware in a machine
570 is properly shutdown, so do not be surprised if this code does not
571 initially work for you. It may help to enable device hotplugging
572 support. As of this writing the exact hardware interface is
573 strongly in flux, so no good recommendation can be made.
576 bool "kernel crash dumps (EXPERIMENTAL)"
577 depends on EXPERIMENTAL
579 Generate crash dump after being started by kexec.
580 This should be normally only set in special crash dump kernels
581 which are loaded in the main kernel with kexec-tools into
582 a specially reserved region and then later executed after
583 a crash by kdump/kexec. The crash dump kernel must be compiled
584 to a memory address not used by the main kernel or BIOS using
585 PHYSICAL_START, or it must be built as a relocatable image
586 (CONFIG_RELOCATABLE=y).
587 For more details see Documentation/kdump/kdump.txt
590 bool "Build a relocatable kernel (EXPERIMENTAL)"
591 depends on EXPERIMENTAL
593 Builds a relocatable kernel. This enables loading and running
594 a kernel binary from a different physical address than it has
597 One use is for the kexec on panic case where the recovery kernel
598 must live at a different physical address than the primary
601 Note: If CONFIG_RELOCATABLE=y, then the kernel runs from the address
602 it has been loaded at and the compile time physical address
603 (CONFIG_PHYSICAL_START) is ignored.
605 config PHYSICAL_START
606 hex "Physical address where the kernel is loaded" if (EMBEDDED || CRASH_DUMP)
609 This gives the physical address where the kernel is loaded. It
610 should be aligned to 2MB boundary.
612 If kernel is a not relocatable (CONFIG_RELOCATABLE=n) then
613 bzImage will decompress itself to above physical address and
614 run from there. Otherwise, bzImage will run from the address where
615 it has been loaded by the boot loader and will ignore above physical
618 In normal kdump cases one does not have to set/change this option
619 as now bzImage can be compiled as a completely relocatable image
620 (CONFIG_RELOCATABLE=y) and be used to load and run from a different
621 address. This option is mainly useful for the folks who don't want
622 to use a bzImage for capturing the crash dump and want to use a
625 So if you are using bzImage for capturing the crash dump, leave
626 the value here unchanged to 0x200000 and set CONFIG_RELOCATABLE=y.
627 Otherwise if you plan to use vmlinux for capturing the crash dump
628 change this value to start of the reserved region (Typically 16MB
629 0x1000000). In other words, it can be set based on the "X" value as
630 specified in the "crashkernel=YM@XM" command line boot parameter
631 passed to the panic-ed kernel. Typically this parameter is set as
632 crashkernel=64M@16M. Please take a look at
633 Documentation/kdump/kdump.txt for more details about crash dumps.
635 Usage of bzImage for capturing the crash dump is advantageous as
636 one does not have to build two kernels. Same kernel can be used
637 as production kernel and capture kernel.
639 Don't change this unless you know what you are doing.
642 bool "Enable seccomp to safely compute untrusted bytecode"
646 This kernel feature is useful for number crunching applications
647 that may need to compute untrusted bytecode during their
648 execution. By using pipes or other transports made available to
649 the process as file descriptors supporting the read/write
650 syscalls, it's possible to isolate those applications in
651 their own address space using seccomp. Once seccomp is
652 enabled via /proc/<pid>/seccomp, it cannot be disabled
653 and the task is only allowed to execute a few safe syscalls
654 defined by each seccomp mode.
656 If unsure, say Y. Only embedded should say N here.
658 config CC_STACKPROTECTOR
659 bool "Enable -fstack-protector buffer overflow detection (EXPERIMENTAL)"
660 depends on EXPERIMENTAL
662 This option turns on the -fstack-protector GCC feature. This
663 feature puts, at the beginning of critical functions, a canary
664 value on the stack just before the return address, and validates
665 the value just before actually returning. Stack based buffer
666 overflows (that need to overwrite this return address) now also
667 overwrite the canary, which gets detected and the attack is then
668 neutralized via a kernel panic.
670 This feature requires gcc version 4.2 or above, or a distribution
671 gcc with the feature backported. Older versions are automatically
672 detected and for those versions, this configuration option is ignored.
674 config CC_STACKPROTECTOR_ALL
675 bool "Use stack-protector for all functions"
676 depends on CC_STACKPROTECTOR
678 Normally, GCC only inserts the canary value protection for
679 functions that use large-ish on-stack buffers. By enabling
680 this option, GCC will be asked to do this for ALL functions.
682 source kernel/Kconfig.hz
686 depends on AGP_AMD64 || GART_IOMMU || (PCI && NUMA)
691 # Use the generic interrupt handling code in kernel/irq/:
693 config GENERIC_HARDIRQS
697 config GENERIC_IRQ_PROBE
701 # we have no ISA slots, but we do have ISA-style DMA.
706 config GENERIC_PENDING_IRQ
708 depends on GENERIC_HARDIRQS && SMP
711 menu "Power management options"
713 source kernel/power/Kconfig
715 config ARCH_HIBERNATION_HEADER
717 depends on HIBERNATION
720 source "drivers/acpi/Kconfig"
722 source "arch/x86/kernel/cpu/cpufreq/Kconfig_64"
724 source "drivers/cpuidle/Kconfig"
728 menu "Bus options (PCI etc.)"
732 select ARCH_SUPPORTS_MSI if (X86_LOCAL_APIC && X86_IO_APIC)
734 # x86-64 doesn't support PCI BIOS access from long mode so always go direct.
741 bool "Support mmconfig PCI config space access"
742 depends on PCI && ACPI
750 bool "Support for DMA Remapping Devices (EXPERIMENTAL)"
751 depends on PCI_MSI && ACPI && EXPERIMENTAL
753 DMA remapping (DMAR) devices support enables independent address
754 translations for Direct Memory Access (DMA) from devices.
755 These DMA remapping devices are reported via ACPI tables
756 and include PCI device scope covered by these DMA
760 bool "Support for Graphics workaround"
764 Current Graphics drivers tend to use physical address
765 for DMA and avoid using DMA APIs. Setting this config
766 option permits the IOMMU driver to set a unity map for
767 all the OS-visible memory. Hence the driver can continue
768 to use physical addresses for DMA.
770 config DMAR_FLOPPY_WA
775 Floppy disk drivers are know to bypass DMA API calls
776 thereby failing to work when IOMMU is enabled. This
777 workaround will setup a 1:1 mapping for the first
778 16M to make floppy (an ISA device) work.
780 source "drivers/pci/pcie/Kconfig"
782 source "drivers/pci/Kconfig"
784 source "drivers/pcmcia/Kconfig"
786 source "drivers/pci/hotplug/Kconfig"
791 menu "Executable file formats / Emulations"
793 source "fs/Kconfig.binfmt"
795 config IA32_EMULATION
796 bool "IA32 Emulation"
798 Include code to run 32-bit programs under a 64-bit kernel. You should
799 likely turn this on, unless you're 100% sure that you don't have any
800 32-bit programs left.
803 tristate "IA32 a.out support"
804 depends on IA32_EMULATION
806 Support old a.out binaries in the 32bit emulation.
810 depends on IA32_EMULATION
813 config COMPAT_FOR_U64_ALIGNMENT
816 config SYSVIPC_COMPAT
818 depends on COMPAT && SYSVIPC
825 source drivers/Kconfig
827 source "drivers/firmware/Kconfig"
831 source "kernel/Kconfig.instrumentation"
833 source "arch/x86/Kconfig.debug"
835 source "security/Kconfig"
837 source "crypto/Kconfig"