Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux...
[sfrench/cifs-2.6.git] / arch / x86 / Kconfig
index 35dd8f147f992e504057975816960b8c66b56f3a..0cb1756223bef01d84a984398965a31c16fc75a2 100644 (file)
@@ -24,7 +24,7 @@ config X86_64
        depends on 64BIT
        # Options that are inherently 64-bit kernel only:
        select ARCH_HAS_GIGANTIC_PAGE
-       select ARCH_SUPPORTS_INT128
+       select ARCH_SUPPORTS_INT128 if CC_HAS_INT128
        select ARCH_USE_CMPXCHG_LOCKREF
        select HAVE_ARCH_SOFT_DIRTY
        select MODULES_USE_ELF_RELA
@@ -73,7 +73,6 @@ config X86
        select ARCH_HAS_PMEM_API                if X86_64
        select ARCH_HAS_PTE_DEVMAP              if X86_64
        select ARCH_HAS_PTE_SPECIAL
-       select ARCH_HAS_REFCOUNT
        select ARCH_HAS_UACCESS_FLUSHCACHE      if X86_64
        select ARCH_HAS_UACCESS_MCSAFE          if X86_64 && X86_MCE
        select ARCH_HAS_SET_MEMORY
@@ -158,6 +157,7 @@ config X86
        select HAVE_DMA_CONTIGUOUS
        select HAVE_DYNAMIC_FTRACE
        select HAVE_DYNAMIC_FTRACE_WITH_REGS
+       select HAVE_DYNAMIC_FTRACE_WITH_DIRECT_CALLS
        select HAVE_EBPF_JIT
        select HAVE_EFFICIENT_UNALIGNED_ACCESS
        select HAVE_EISA
@@ -931,36 +931,6 @@ config GART_IOMMU
 
          If unsure, say Y.
 
-config CALGARY_IOMMU
-       bool "IBM Calgary IOMMU support"
-       select IOMMU_HELPER
-       select SWIOTLB
-       depends on X86_64 && PCI
-       ---help---
-         Support for hardware IOMMUs in IBM's xSeries x366 and x460
-         systems. Needed to run systems with more than 3GB of memory
-         properly with 32-bit PCI devices that do not support DAC
-         (Double Address Cycle). Calgary also supports bus level
-         isolation, where all DMAs pass through the IOMMU.  This
-         prevents them from going anywhere except their intended
-         destination. This catches hard-to-find kernel bugs and
-         mis-behaving drivers and devices that do not use the DMA-API
-         properly to set up their DMA buffers.  The IOMMU can be
-         turned off at boot time with the iommu=off parameter.
-         Normally the kernel will make the right choice by itself.
-         If unsure, say Y.
-
-config CALGARY_IOMMU_ENABLED_BY_DEFAULT
-       def_bool y
-       prompt "Should Calgary be enabled by default?"
-       depends on CALGARY_IOMMU
-       ---help---
-         Should Calgary be enabled by default? if you choose 'y', Calgary
-         will be used (if it exists). If you choose 'n', Calgary will not be
-         used even if it exists. If you choose 'n' and would like to use
-         Calgary anyway, pass 'iommu=calgary' on the kernel command line.
-         If unsure, say Y.
-
 config MAXSMP
        bool "Enable Maximum number of SMP Processors and NUMA Nodes"
        depends on X86_64 && SMP && DEBUG_KERNEL
@@ -999,8 +969,8 @@ config NR_CPUS_RANGE_END
 config NR_CPUS_RANGE_END
        int
        depends on X86_64
-       default 8192 if  SMP && ( MAXSMP ||  CPUMASK_OFFSTACK)
-       default  512 if  SMP && (!MAXSMP && !CPUMASK_OFFSTACK)
+       default 8192 if  SMP && CPUMASK_OFFSTACK
+       default  512 if  SMP && !CPUMASK_OFFSTACK
        default    1 if !SMP
 
 config NR_CPUS_DEFAULT
@@ -1253,6 +1223,24 @@ config X86_VSYSCALL_EMULATION
         Disabling this option saves about 7K of kernel size and
         possibly 4K of additional runtime pagetable memory.
 
+config X86_IOPL_IOPERM
+       bool "IOPERM and IOPL Emulation"
+       default y
+       ---help---
+         This enables the ioperm() and iopl() syscalls which are necessary
+         for legacy applications.
+
+         Legacy IOPL support is an overbroad mechanism which allows user
+         space aside of accessing all 65536 I/O ports also to disable
+         interrupts. To gain this access the caller needs CAP_SYS_RAWIO
+         capabilities and permission from potentially active security
+         modules.
+
+         The emulation restricts the functionality of the syscall to
+         only allowing the full range I/O port access, but prevents the
+         ability to disable interrupts from user space which would be
+         granted if the hardware IOPL mechanism would be used.
+
 config TOSHIBA
        tristate "Toshiba Laptop support"
        depends on X86_32
@@ -1491,6 +1479,7 @@ config X86_PAE
 
 config X86_5LEVEL
        bool "Enable 5-level page tables support"
+       default y
        select DYNAMIC_MEMORY_LAYOUT
        select SPARSEMEM_VMEMMAP
        depends on X86_64
@@ -1750,7 +1739,7 @@ config X86_RESERVE_LOW
 config MATH_EMULATION
        bool
        depends on MODIFY_LDT_SYSCALL
-       prompt "Math emulation" if X86_32
+       prompt "Math emulation" if X86_32 && (M486SX || MELAN)
        ---help---
          Linux can emulate a math coprocessor (used for floating point
          operations) if you don't have one. 486DX and Pentium processors have
@@ -1879,16 +1868,16 @@ config X86_SMAP
 
          If unsure, say Y.
 
-config X86_INTEL_UMIP
+config X86_UMIP
        def_bool y
-       depends on CPU_SUP_INTEL
-       prompt "Intel User Mode Instruction Prevention" if EXPERT
+       depends on CPU_SUP_INTEL || CPU_SUP_AMD
+       prompt "User Mode Instruction Prevention" if EXPERT
        ---help---
-         The User Mode Instruction Prevention (UMIP) is a security
-         feature in newer Intel processors. If enabled, a general
-         protection fault is issued if the SGDT, SLDT, SIDT, SMSW
-         or STR instructions are executed in user mode. These instructions
-         unnecessarily expose information about the hardware state.
+         User Mode Instruction Prevention (UMIP) is a security feature in
+         some x86 processors. If enabled, a general protection fault is
+         issued if the SGDT, SLDT, SIDT, SMSW or STR instructions are
+         executed in user mode. These instructions unnecessarily expose
+         information about the hardware state.
 
          The vast majority of applications do not use these instructions.
          For the very few that do, software emulation is provided in
@@ -1939,6 +1928,51 @@ config X86_INTEL_MEMORY_PROTECTION_KEYS
 
          If unsure, say y.
 
+choice
+       prompt "TSX enable mode"
+       depends on CPU_SUP_INTEL
+       default X86_INTEL_TSX_MODE_OFF
+       help
+         Intel's TSX (Transactional Synchronization Extensions) feature
+         allows to optimize locking protocols through lock elision which
+         can lead to a noticeable performance boost.
+
+         On the other hand it has been shown that TSX can be exploited
+         to form side channel attacks (e.g. TAA) and chances are there
+         will be more of those attacks discovered in the future.
+
+         Therefore TSX is not enabled by default (aka tsx=off). An admin
+         might override this decision by tsx=on the command line parameter.
+         Even with TSX enabled, the kernel will attempt to enable the best
+         possible TAA mitigation setting depending on the microcode available
+         for the particular machine.
+
+         This option allows to set the default tsx mode between tsx=on, =off
+         and =auto. See Documentation/admin-guide/kernel-parameters.txt for more
+         details.
+
+         Say off if not sure, auto if TSX is in use but it should be used on safe
+         platforms or on if TSX is in use and the security aspect of tsx is not
+         relevant.
+
+config X86_INTEL_TSX_MODE_OFF
+       bool "off"
+       help
+         TSX is disabled if possible - equals to tsx=off command line parameter.
+
+config X86_INTEL_TSX_MODE_ON
+       bool "on"
+       help
+         TSX is always enabled on TSX capable HW - equals the tsx=on command
+         line parameter.
+
+config X86_INTEL_TSX_MODE_AUTO
+       bool "auto"
+       help
+         TSX is enabled on TSX capable HW that is believed to be safe against
+         side channel attacks- equals the tsx=auto command line parameter.
+endchoice
+
 config EFI
        bool "EFI runtime service support"
        depends on ACPI