Merge commit 'linus/master' into HEAD
[safe/jmp/linux-2.6] / arch / x86 / Kconfig
index 0885245..cf42fc3 100644 (file)
@@ -46,6 +46,12 @@ config X86
        select HAVE_KERNEL_GZIP
        select HAVE_KERNEL_BZIP2
        select HAVE_KERNEL_LZMA
+       select HAVE_ARCH_KMEMCHECK
+
+config OUTPUT_FORMAT
+       string
+       default "elf32-i386" if X86_32
+       default "elf64-x86-64" if X86_64
 
 config ARCH_DEFCONFIG
        string
@@ -252,16 +258,13 @@ config SMP
 
 config X86_X2APIC
        bool "Support x2apic"
-       depends on X86_LOCAL_APIC && X86_64
+       depends on X86_LOCAL_APIC && X86_64 && INTR_REMAP
        ---help---
          This enables x2apic support on CPUs that have this feature.
 
          This allows 32-bit apic IDs (so it can support very large systems),
          and accesses the local apic via MSRs not via mmio.
 
-         ( On certain CPU models you may need to enable INTR_REMAP too,
-           to get functional x2apic mode. )
-
          If you don't know what to do here, say N.
 
 config SPARSE_IRQ
@@ -277,14 +280,9 @@ config SPARSE_IRQ
 
          If you don't know what to do here, say N.
 
-config NUMA_MIGRATE_IRQ_DESC
-       bool "Move irq desc when changing irq smp_affinity"
+config NUMA_IRQ_DESC
+       def_bool y
        depends on SPARSE_IRQ && NUMA
-       default n
-       ---help---
-         This enables moving irq_desc to cpu/node that irq will use handled.
-
-         If you don't know what to do here, say N.
 
 config X86_MPPARSE
        bool "Enable MPS table" if ACPI
@@ -356,7 +354,8 @@ config X86_UV
        bool "SGI Ultraviolet"
        depends on X86_64
        depends on X86_EXTENDED_PLATFORM
-       select X86_X2APIC
+       depends on NUMA
+       depends on X86_X2APIC
        ---help---
          This option is needed in order to support SGI Ultraviolet systems.
          If you don't have one of these, you should say N here.
@@ -499,6 +498,19 @@ config PARAVIRT
          over full virtualization.  However, when run without a hypervisor
          the kernel is theoretically slower and slightly larger.
 
+config PARAVIRT_SPINLOCKS
+       bool "Paravirtualization layer for spinlocks"
+       depends on PARAVIRT && SMP && EXPERIMENTAL
+       ---help---
+         Paravirtualized spinlocks allow a pvops backend to replace the
+         spinlock implementation with something virtualization-friendly
+         (for example, block the virtual CPU rather than spinning).
+
+         Unfortunately the downside is an up to 5% performance hit on
+         native kernels, with various workloads.
+
+         If you are unsure how to answer this question, answer N.
+
 config PARAVIRT_CLOCK
        bool
        default n
@@ -666,6 +678,7 @@ config MAXSMP
 
 config NR_CPUS
        int "Maximum number of CPUs" if SMP && !MAXSMP
+       range 2 8 if SMP && X86_32 && !X86_BIGSMP
        range 2 512 if SMP && !MAXSMP
        default "1" if !SMP
        default "4096" if MAXSMP
@@ -727,6 +740,7 @@ config X86_UP_IOAPIC
 config X86_LOCAL_APIC
        def_bool y
        depends on X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_APIC
+       select HAVE_PERF_COUNTERS if (!M386 && !M486)
 
 config X86_IO_APIC
        def_bool y
@@ -776,10 +790,26 @@ config X86_MCE
          to disable it.  MCE support simply ignores non-MCE processors like
          the 386 and 486, so nearly everyone can say Y here.
 
+config X86_OLD_MCE
+       depends on X86_32 && X86_MCE
+       bool "Use legacy machine check code (will go away)"
+       default n
+       select X86_ANCIENT_MCE
+       ---help---
+         Use the old i386 machine check code. This is merely intended for
+         testing in a transition period. Try this if you run into any machine
+         check related software problems, but report the problem to
+         linux-kernel.  When in doubt say no.
+
+config X86_NEW_MCE
+       depends on X86_MCE
+       bool
+       default y if (!X86_OLD_MCE && X86_32) || X86_64
+
 config X86_MCE_INTEL
        def_bool y
        prompt "Intel MCE features"
-       depends on X86_64 && X86_MCE && X86_LOCAL_APIC
+       depends on X86_NEW_MCE && X86_LOCAL_APIC
        ---help---
           Additional support for intel specific MCE features such as
           the thermal monitor.
@@ -787,19 +817,36 @@ config X86_MCE_INTEL
 config X86_MCE_AMD
        def_bool y
        prompt "AMD MCE features"
-       depends on X86_64 && X86_MCE && X86_LOCAL_APIC
+       depends on X86_NEW_MCE && X86_LOCAL_APIC
        ---help---
           Additional support for AMD specific MCE features such as
           the DRAM Error Threshold.
 
+config X86_ANCIENT_MCE
+       def_bool n
+       depends on X86_32
+       prompt "Support for old Pentium 5 / WinChip machine checks"
+       ---help---
+         Include support for machine check handling on old Pentium 5 or WinChip
+         systems. These typically need to be enabled explicitely on the command
+         line.
+
 config X86_MCE_THRESHOLD
        depends on X86_MCE_AMD || X86_MCE_INTEL
        bool
        default y
 
+config X86_MCE_INJECT
+       depends on X86_NEW_MCE
+       tristate "Machine check injector support"
+       ---help---
+         Provide support for injecting machine checks for testing purposes.
+         If you don't know what a machine check is and you don't do kernel
+         QA it is safe to say n.
+
 config X86_MCE_NONFATAL
        tristate "Check for non-fatal errors on AMD Athlon/Duron / Intel Pentium 4"
-       depends on X86_32 && X86_MCE
+       depends on X86_OLD_MCE
        ---help---
          Enabling this feature starts a timer that triggers every 5 seconds which
          will look at the machine check registers to see if anything happened.
@@ -812,11 +859,15 @@ config X86_MCE_NONFATAL
 
 config X86_MCE_P4THERMAL
        bool "check for P4 thermal throttling interrupt."
-       depends on X86_32 && X86_MCE && (X86_UP_APIC || SMP)
+       depends on X86_OLD_MCE && X86_MCE && (X86_UP_APIC || SMP)
        ---help---
          Enabling this feature will cause a message to be printed when the P4
          enters thermal throttling.
 
+config X86_THERMAL_VECTOR
+       def_bool y
+       depends on X86_MCE_P4THERMAL || X86_MCE_INTEL
+
 config VM86
        bool "Enable VM86 support" if EMBEDDED
        default y
@@ -1146,7 +1197,7 @@ config NODES_SHIFT
        depends on NEED_MULTIPLE_NODES
        ---help---
          Specify the maximum number of NUMA Nodes available on the target
-         system.  Increases memory reserved to accomodate various tables.
+         system.  Increases memory reserved to accommodate various tables.
 
 config HAVE_ARCH_BOOTMEM
        def_bool y
@@ -1324,7 +1375,7 @@ config MTRR_SANITIZER
          add writeback entries.
 
          Can be disabled with disable_mtrr_cleanup on the kernel command line.
-         The largest mtrr entry size for a continous block can be set with
+         The largest mtrr entry size for a continuous block can be set with
          mtrr_chunk_size.
 
          If unsure, say Y.
@@ -1453,9 +1504,7 @@ config KEXEC_JUMP
 
 config PHYSICAL_START
        hex "Physical address where the kernel is loaded" if (EMBEDDED || CRASH_DUMP)
-       default "0x1000000" if X86_NUMAQ
-       default "0x200000" if X86_64
-       default "0x100000"
+       default "0x1000000"
        ---help---
          This gives the physical address where the kernel is loaded.
 
@@ -1474,15 +1523,15 @@ config PHYSICAL_START
          to be specifically compiled to run from a specific memory area
          (normally a reserved region) and this option comes handy.
 
-         So if you are using bzImage for capturing the crash dump, leave
-         the value here unchanged to 0x100000 and set CONFIG_RELOCATABLE=y.
-         Otherwise if you plan to use vmlinux for capturing the crash dump
-         change this value to start of the reserved region (Typically 16MB
-         0x1000000). In other words, it can be set based on the "X" value as
-         specified in the "crashkernel=YM@XM" command line boot parameter
-         passed to the panic-ed kernel. Typically this parameter is set as
-         crashkernel=64M@16M. Please take a look at
-         Documentation/kdump/kdump.txt for more details about crash dumps.
+         So if you are using bzImage for capturing the crash dump,
+         leave the value here unchanged to 0x1000000 and set
+         CONFIG_RELOCATABLE=y.  Otherwise if you plan to use vmlinux
+         for capturing the crash dump change this value to start of
+         the reserved region.  In other words, it can be set based on
+         the "X" value as specified in the "crashkernel=YM@XM"
+         command line boot parameter passed to the panic-ed
+         kernel. Please take a look at Documentation/kdump/kdump.txt
+         for more details about crash dumps.
 
          Usage of bzImage for capturing the crash dump is recommended as
          one does not have to build two kernels. Same kernel can be used
@@ -1495,8 +1544,8 @@ config PHYSICAL_START
          Don't change this unless you know what you are doing.
 
 config RELOCATABLE
-       bool "Build a relocatable kernel (EXPERIMENTAL)"
-       depends on EXPERIMENTAL
+       bool "Build a relocatable kernel"
+       default y
        ---help---
          This builds a kernel image that retains relocation information
          so it can be loaded someplace besides the default 1MB.
@@ -1511,12 +1560,16 @@ config RELOCATABLE
          it has been loaded at and the compile time physical address
          (CONFIG_PHYSICAL_START) is ignored.
 
+# Relocation on x86-32 needs some additional build support
+config X86_NEED_RELOCS
+       def_bool y
+       depends on X86_32 && RELOCATABLE
+
 config PHYSICAL_ALIGN
        hex
        prompt "Alignment value to which kernel should be aligned" if X86_32
-       default "0x100000" if X86_32
-       default "0x200000" if X86_64
-       range 0x2000 0x400000
+       default "0x1000000"
+       range 0x2000 0x1000000
        ---help---
          This value puts the alignment restrictions on physical address
          where kernel is loaded and run from. Kernel is compiled for an
@@ -1839,8 +1892,8 @@ config PCI_MMCONFIG
 
 config DMAR
        bool "Support for DMA Remapping Devices (EXPERIMENTAL)"
-       depends on X86_64 && PCI_MSI && ACPI && EXPERIMENTAL
-       ---help---
+       depends on PCI_MSI && ACPI && EXPERIMENTAL
+       help
          DMA remapping (DMAR) devices support enables independent address
          translations for Direct Memory Access (DMA) from devices.
          These DMA remapping devices are reported via ACPI tables
@@ -1881,7 +1934,6 @@ config DMAR_FLOPPY_WA
 config INTR_REMAP
        bool "Support for Interrupt Remapping (EXPERIMENTAL)"
        depends on X86_64 && X86_IO_APIC && PCI_MSI && ACPI && EXPERIMENTAL
-       select X86_X2APIC
        ---help---
          Supports Interrupt remapping for IO-APIC and MSI devices.
          To use x2apic mode in the CPU's which support x2APIC enhancements or