* [PATCH 01/12] x86 Kconfig: create extended platforms menu
2014-01-13 19:22 [PATCH 00/12] [v2] Reorganize x86 Kconfig menu Dave Hansen
@ 2014-01-13 19:22 ` Dave Hansen
2014-01-13 19:22 ` [PATCH 02/12] x86 Kconfig: memory options Dave Hansen
` (11 subsequent siblings)
12 siblings, 0 replies; 19+ messages in thread
From: Dave Hansen @ 2014-01-13 19:22 UTC (permalink / raw)
To: linux-kernel; +Cc: x86, Dave Hansen
From: Dave Hansen <dave.hansen@linux.intel.com>
This takes the relatively obscure (NUMA-Q anyone?) platforms
(both 32 and 64-bit) and sticks them in their own menu.
Virtually nobody needs to set these, and those that do know how
to find them the hard way.
The new menu is also moved to the end of the x86 options.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
---
linux.git-davehans/arch/x86/Kconfig | 293 +++++++++++++++++-------------------
1 file changed, 141 insertions(+), 152 deletions(-)
diff -puN arch/x86/Kconfig~x86-extended-platforms arch/x86/Kconfig
--- linux.git/arch/x86/Kconfig~x86-extended-platforms 2014-01-13 11:11:34.511160641 -0800
+++ linux.git-davehans/arch/x86/Kconfig 2014-01-13 11:11:34.514160776 -0800
@@ -331,122 +331,6 @@ config GOLDFISH
def_bool y
depends on X86_GOLDFISH
-if X86_32
-config X86_EXTENDED_PLATFORM
- bool "Support for extended (non-PC) x86 platforms"
- default y
- ---help---
- If you disable this option then the kernel will only support
- standard PC platforms. (which covers the vast majority of
- systems out there.)
-
- If you enable this option then you'll be able to select support
- for the following (non-PC) 32 bit x86 platforms:
- Goldfish (Android emulator)
- AMD Elan
- NUMAQ (IBM/Sequent)
- RDC R-321x SoC
- SGI 320/540 (Visual Workstation)
- STA2X11-based (e.g. Northville)
- Summit/EXA (IBM x440)
- Unisys ES7000 IA32 series
- Moorestown MID devices
-
- If you have one of these systems, or if you want to build a
- generic distribution kernel, say Y here - otherwise say N.
-endif
-
-if X86_64
-config X86_EXTENDED_PLATFORM
- bool "Support for extended (non-PC) x86 platforms"
- default y
- ---help---
- If you disable this option then the kernel will only support
- standard PC platforms. (which covers the vast majority of
- systems out there.)
-
- If you enable this option then you'll be able to select support
- for the following (non-PC) 64 bit x86 platforms:
- Numascale NumaChip
- ScaleMP vSMP
- SGI Ultraviolet
-
- If you have one of these systems, or if you want to build a
- generic distribution kernel, say Y here - otherwise say N.
-endif
-# This is an alphabetically sorted list of 64 bit extended platforms
-# Please maintain the alphabetic order if and when there are additions
-config X86_NUMACHIP
- bool "Numascale NumaChip"
- depends on X86_64
- depends on X86_EXTENDED_PLATFORM
- depends on NUMA
- depends on SMP
- depends on X86_X2APIC
- depends on PCI_MMCONFIG
- ---help---
- Adds support for Numascale NumaChip large-SMP systems. Needed to
- enable more than ~168 cores.
- If you don't have one of these, you should say N here.
-
-config X86_VSMP
- bool "ScaleMP vSMP"
- select HYPERVISOR_GUEST
- select PARAVIRT
- depends on X86_64 && PCI
- depends on X86_EXTENDED_PLATFORM
- depends on SMP
- ---help---
- Support for ScaleMP vSMP systems. Say 'Y' here if this kernel is
- supposed to run on these EM64T-based machines. Only choose this option
- if you have one of these machines.
-
-config X86_UV
- bool "SGI Ultraviolet"
- depends on X86_64
- depends on X86_EXTENDED_PLATFORM
- 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.
-
-# Following is an alphabetically sorted list of 32 bit extended platforms
-# Please maintain the alphabetic order if and when there are additions
-
-config X86_GOLDFISH
- bool "Goldfish (Virtual Platform)"
- depends on X86_32
- depends on X86_EXTENDED_PLATFORM
- ---help---
- Enable support for the Goldfish virtual platform used primarily
- for Android development. Unless you are building for the Android
- Goldfish emulator say N here.
-
-config X86_INTEL_CE
- bool "CE4100 TV platform"
- depends on PCI
- depends on PCI_GODIRECT
- depends on X86_32
- depends on X86_EXTENDED_PLATFORM
- select X86_REBOOTFIXUPS
- select OF
- select OF_EARLY_FLATTREE
- select IRQ_DOMAIN
- ---help---
- Select for the Intel CE media processor (CE4100) SOC.
- This option compiles in support for the CE4100 SOC for settop
- boxes and media devices.
-
-config X86_WANT_INTEL_MID
- bool "Intel MID platform support"
- depends on X86_32
- depends on X86_EXTENDED_PLATFORM
- ---help---
- Select to build a kernel capable of supporting Intel MID platform
- systems which do not have the PCI legacy interfaces (Moorestown,
- Medfield). If you are building for a PC class system say N here.
-
if X86_WANT_INTEL_MID
config X86_INTEL_MID
@@ -486,42 +370,6 @@ config X86_INTEL_LPSS
things like clock tree (common clock framework) and pincontrol
which are needed by the LPSS peripheral drivers.
-config X86_RDC321X
- bool "RDC R-321x SoC"
- depends on X86_32
- depends on X86_EXTENDED_PLATFORM
- select M486
- select X86_REBOOTFIXUPS
- ---help---
- This option is needed for RDC R-321x system-on-chip, also known
- as R-8610-(G).
- If you don't have one of these chips, you should say N here.
-
-config X86_32_NON_STANDARD
- bool "Support non-standard 32-bit SMP architectures"
- depends on X86_32 && SMP
- depends on X86_EXTENDED_PLATFORM
- ---help---
- This option compiles in the NUMAQ, Summit, bigsmp, ES7000,
- STA2X11, default subarchitectures. It is intended for a generic
- binary kernel. If you select them all, kernel will probe it
- one by one and will fallback to default.
-
-# Alphabetically sorted list of Non standard 32 bit platforms
-
-config X86_NUMAQ
- bool "NUMAQ (IBM/Sequent)"
- depends on X86_32_NON_STANDARD
- depends on PCI
- select NUMA
- select X86_MPPARSE
- ---help---
- This option is used for getting Linux to run on a NUMAQ (IBM/Sequent)
- NUMA multiquad box. This changes the way that processors are
- bootstrapped, and uses Clustered Logical APIC addressing mode instead
- of Flat Logical. You will need a new lynxer.elf file to flash your
- firmware with - send email to <Martin.Bligh@us.ibm.com>.
-
config X86_SUPPORTS_MEMORY_FAILURE
def_bool y
# MCE code calls memory_failure():
@@ -1872,6 +1720,147 @@ config CMDLINE_OVERRIDE
This is used to work around broken boot loaders. This should
be set to 'N' under normal conditions.
+menuconfig X86_EXTENDED_PLATFORM
+ bool "Support for extended (non-PC) x86 platforms"
+ default y
+ ---help---
+ If you disable this option then the kernel will only support
+ standard PC platforms. (which covers the vast majority of
+ systems out there.)
+
+ If you enable this option then you'll be able to select support
+ for the following (non-PC) 64 bit x86 platforms:
+ Numascale NumaChip
+ ScaleMP vSMP
+ SGI Ultraviolet
+
+ and these (non-PC) 32 bit x86 platforms:
+ Goldfish (Android emulator)
+ AMD Elan
+ NUMAQ (IBM/Sequent)
+ RDC R-321x SoC
+ SGI 320/540 (Visual Workstation)
+ STA2X11-based (e.g. Northville)
+ Summit/EXA (IBM x440)
+ Unisys ES7000 IA32 series
+ Moorestown MID devices
+
+ If you have one of these systems, or if you want to build a
+ generic distribution kernel, say Y here - otherwise say N.
+
+if X86_EXTENDED_PLATFORM
+
+# This is an alphabetically sorted list of 64 bit extended platforms
+# Please maintain the alphabetic order if and when there are additions
+config X86_NUMACHIP
+ bool "Numascale NumaChip"
+ depends on X86_64
+ depends on X86_EXTENDED_PLATFORM
+ depends on NUMA
+ depends on SMP
+ depends on X86_X2APIC
+ depends on PCI_MMCONFIG
+ ---help---
+ Adds support for Numascale NumaChip large-SMP systems. Needed to
+ enable more than ~168 cores.
+ If you don't have one of these, you should say N here.
+
+config X86_VSMP
+ bool "ScaleMP vSMP"
+ select HYPERVISOR_GUEST
+ select PARAVIRT
+ depends on X86_64 && PCI
+ depends on X86_EXTENDED_PLATFORM
+ depends on SMP
+ ---help---
+ Support for ScaleMP vSMP systems. Say 'Y' here if this kernel is
+ supposed to run on these EM64T-based machines. Only choose this option
+ if you have one of these machines.
+
+config X86_UV
+ bool "SGI Ultraviolet"
+ depends on X86_64
+ depends on X86_EXTENDED_PLATFORM
+ 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.
+
+# Following is an alphabetically sorted list of 32 bit extended platforms
+# Please maintain the alphabetic order if and when there are additions
+
+config X86_GOLDFISH
+ bool "Goldfish (Virtual Platform)"
+ depends on X86_32
+ depends on X86_EXTENDED_PLATFORM
+ ---help---
+ Enable support for the Goldfish virtual platform used primarily
+ for Android development. Unless you are building for the Android
+ Goldfish emulator say N here.
+
+config X86_INTEL_CE
+ bool "CE4100 TV platform"
+ depends on PCI
+ depends on PCI_GODIRECT
+ depends on X86_32
+ depends on X86_EXTENDED_PLATFORM
+ select X86_REBOOTFIXUPS
+ select OF
+ select OF_EARLY_FLATTREE
+ select IRQ_DOMAIN
+ ---help---
+ Select for the Intel CE media processor (CE4100) SOC.
+ This option compiles in support for the CE4100 SOC for settop
+ boxes and media devices.
+
+config X86_WANT_INTEL_MID
+ bool "Intel MID platform support"
+ depends on X86_32
+ depends on X86_EXTENDED_PLATFORM
+ ---help---
+ Select to build a kernel capable of supporting Intel MID platform
+ systems which do not have the PCI legacy interfaces (Moorestown,
+ Medfield). If you are building for a PC class system say N here.
+
+config X86_RDC321X
+ bool "RDC R-321x SoC"
+ depends on X86_32
+ depends on X86_EXTENDED_PLATFORM
+ select M486
+ select X86_REBOOTFIXUPS
+ ---help---
+ This option is needed for RDC R-321x system-on-chip, also known
+ as R-8610-(G).
+ If you don't have one of these chips, you should say N here.
+
+config X86_32_NON_STANDARD
+ bool "Support non-standard 32-bit SMP architectures"
+ depends on X86_32 && SMP
+ depends on X86_EXTENDED_PLATFORM
+ ---help---
+ This option compiles in the NUMAQ, Summit, bigsmp, ES7000,
+ STA2X11, default subarchitectures. It is intended for a generic
+ binary kernel. If you select them all, kernel will probe it
+ one by one and will fallback to default.
+
+# Alphabetically sorted list of Non standard 32 bit platforms
+
+config X86_NUMAQ
+ bool "NUMAQ (IBM/Sequent)"
+ depends on X86_32_NON_STANDARD
+ depends on PCI
+ select NUMA
+ select X86_MPPARSE
+ ---help---
+ This option is used for getting Linux to run on a NUMAQ (IBM/Sequent)
+ NUMA multiquad box. This changes the way that processors are
+ bootstrapped, and uses Clustered Logical APIC addressing mode instead
+ of Flat Logical. You will need a new lynxer.elf file to flash your
+ firmware with - send email to <Martin.Bligh@us.ibm.com>.
+
+endif # X86_EXTENDED_PLATFORM
+
endmenu
config ARCH_ENABLE_MEMORY_HOTPLUG
_
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 02/12] x86 Kconfig: memory options
2014-01-13 19:22 [PATCH 00/12] [v2] Reorganize x86 Kconfig menu Dave Hansen
2014-01-13 19:22 ` [PATCH 01/12] x86 Kconfig: create extended platforms menu Dave Hansen
@ 2014-01-13 19:22 ` Dave Hansen
2014-01-13 19:22 ` [PATCH 03/12] x86 Kconfig: move highmem Dave Hansen
` (10 subsequent siblings)
12 siblings, 0 replies; 19+ messages in thread
From: Dave Hansen @ 2014-01-13 19:22 UTC (permalink / raw)
To: linux-kernel; +Cc: x86, Dave Hansen
From: Dave Hansen <dave.hansen@linux.intel.com>
This consolidates a bunch of VM, memory and NUMA options down to
be under a single Kconfig menu. Most of this stuff is pretty
obscure, like HIGHPTE or ZONE_DMA support. It doesn't really
deserve to be in the top-level menu.
For what it's worth "Processor type and features" seems to have
become mostly a dumping ground for architecture-specific
features. Maybe we should just change the name of the menu too?
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
---
linux.git-davehans/arch/x86/Kconfig | 450 ++++++++++++++++++------------------
1 file changed, 227 insertions(+), 223 deletions(-)
diff -puN arch/x86/Kconfig~x86-memory-options arch/x86/Kconfig
--- linux.git/arch/x86/Kconfig~x86-memory-options 2014-01-13 11:11:34.717169954 -0800
+++ linux.git-davehans/arch/x86/Kconfig 2014-01-13 11:11:34.720170090 -0800
@@ -264,16 +264,6 @@ source "kernel/Kconfig.freezer"
menu "Processor type and features"
-config ZONE_DMA
- bool "DMA memory allocation support" if EXPERT
- default y
- help
- DMA memory allocation support allows devices with less than 32-bit
- addressing to allocate within the first 16MB of address space.
- Disable if no such devices will be used.
-
- If unsure, say Y.
-
config SMP
bool "Symmetric multi-processing support"
---help---
@@ -331,6 +321,233 @@ config GOLDFISH
def_bool y
depends on X86_GOLDFISH
+menu "Memory and NUMA Options"
+
+config ZONE_DMA
+ bool "DMA memory allocation support" if EXPERT
+ default y
+ help
+ DMA memory allocation support allows devices with less than 32-bit
+ addressing to allocate within the first 16MB of address space.
+ Disable if no such devices will be used.
+
+ If unsure, say Y.
+
+config DIRECT_GBPAGES
+ bool "Enable 1GB pages for kernel pagetables" if EXPERT
+ default y
+ depends on X86_64
+ ---help---
+ Allow the kernel linear mapping to use 1GB pages on CPUs that
+ support it. This can improve the kernel's performance a tiny bit by
+ reducing TLB pressure. If in doubt, say "Y".
+
+# Common NUMA Features
+config NUMA
+ bool "Numa Memory Allocation and Scheduler Support"
+ depends on SMP
+ depends on X86_64 || (X86_32 && HIGHMEM64G && (X86_NUMAQ || X86_BIGSMP || X86_SUMMIT && ACPI))
+ default y if (X86_NUMAQ || X86_SUMMIT || X86_BIGSMP)
+ ---help---
+ Enable NUMA (Non Uniform Memory Access) support.
+
+ The kernel will try to allocate memory used by a CPU on the
+ local memory controller of the CPU and add some more
+ NUMA awareness to the kernel.
+
+ For 64-bit this is recommended if the system is Intel Core i7
+ (or later), AMD Opteron, or EM64T NUMA.
+
+ For 32-bit this is only needed on (rare) 32-bit-only platforms
+ that support NUMA topologies, such as NUMAQ / Summit, or if you
+ boot a 32-bit kernel on a 64-bit NUMA platform.
+
+ Otherwise, you should say N.
+
+comment "NUMA (Summit) requires SMP, 64GB highmem support, ACPI"
+ depends on X86_32 && X86_SUMMIT && (!HIGHMEM64G || !ACPI)
+
+config AMD_NUMA
+ def_bool y
+ prompt "Old style AMD Opteron NUMA detection"
+ depends on X86_64 && NUMA && PCI
+ ---help---
+ Enable AMD NUMA node topology detection. You should say Y here if
+ you have a multi processor AMD system. This uses an old method to
+ read the NUMA configuration directly from the builtin Northbridge
+ of Opteron. It is recommended to use X86_64_ACPI_NUMA instead,
+ which also takes priority if both are compiled in.
+
+config X86_64_ACPI_NUMA
+ def_bool y
+ prompt "ACPI NUMA detection"
+ depends on X86_64 && NUMA && ACPI && PCI
+ select ACPI_NUMA
+ ---help---
+ Enable ACPI SRAT based node topology detection.
+
+# Some NUMA nodes have memory ranges that span
+# other nodes. Even though a pfn is valid and
+# between a node's start and end pfns, it may not
+# reside on that node. See memmap_init_zone()
+# for details.
+config NODES_SPAN_OTHER_NODES
+ def_bool y
+ depends on X86_64_ACPI_NUMA
+
+config NUMA_EMU
+ bool "NUMA emulation"
+ depends on NUMA
+ ---help---
+ Enable NUMA emulation. A flat machine will be split
+ into virtual nodes when booted with "numa=fake=N", where N is the
+ number of nodes. This is only useful for debugging.
+
+config NODES_SHIFT
+ int "Maximum NUMA Nodes (as a power of 2)" if !MAXSMP
+ range 1 10
+ default "10" if MAXSMP
+ default "6" if X86_64
+ default "4" if X86_NUMAQ
+ default "3"
+ depends on NEED_MULTIPLE_NODES
+ ---help---
+ Specify the maximum number of NUMA Nodes available on the target
+ system. Increases memory reserved to accommodate various tables.
+
+config ARCH_HAVE_MEMORY_PRESENT
+ def_bool y
+ depends on X86_32 && DISCONTIGMEM
+
+config NEED_NODE_MEMMAP_SIZE
+ def_bool y
+ depends on X86_32 && (DISCONTIGMEM || SPARSEMEM)
+
+config ARCH_FLATMEM_ENABLE
+ def_bool y
+ depends on X86_32 && !NUMA
+
+config ARCH_DISCONTIGMEM_ENABLE
+ def_bool y
+ depends on NUMA && X86_32
+
+config ARCH_DISCONTIGMEM_DEFAULT
+ def_bool y
+ depends on NUMA && X86_32
+
+config ARCH_SPARSEMEM_ENABLE
+ def_bool y
+ depends on X86_64 || NUMA || X86_32 || X86_32_NON_STANDARD
+ select SPARSEMEM_STATIC if X86_32
+ select SPARSEMEM_VMEMMAP_ENABLE if X86_64
+
+config ARCH_SPARSEMEM_DEFAULT
+ def_bool y
+ depends on X86_64
+
+config ARCH_SELECT_MEMORY_MODEL
+ def_bool y
+ depends on ARCH_SPARSEMEM_ENABLE
+
+config ARCH_MEMORY_PROBE
+ bool "Enable sysfs memory/probe interface"
+ depends on X86_64 && MEMORY_HOTPLUG
+ help
+ This option enables a sysfs memory/probe interface for testing.
+ See Documentation/memory-hotplug.txt for more information.
+ If you are unsure how to answer this question, answer N.
+
+config ARCH_PROC_KCORE_TEXT
+ def_bool y
+ depends on X86_64 && PROC_KCORE
+
+config ILLEGAL_POINTER_VALUE
+ hex
+ default 0 if X86_32
+ default 0xdead000000000000 if X86_64
+
+source "mm/Kconfig"
+
+config HIGHPTE
+ bool "Allocate 3rd-level pagetables from highmem"
+ depends on HIGHMEM
+ ---help---
+ The VM uses one page table entry for each page of physical memory.
+ For systems with a lot of RAM, this can be wasteful of precious
+ low memory. Setting this option will put user-space page table
+ entries in high memory.
+
+config X86_CHECK_BIOS_CORRUPTION
+ bool "Check for low memory corruption"
+ ---help---
+ Periodically check for memory corruption in low memory, which
+ is suspected to be caused by BIOS. Even when enabled in the
+ configuration, it is disabled at runtime. Enable it by
+ setting "memory_corruption_check=1" on the kernel command
+ line. By default it scans the low 64k of memory every 60
+ seconds; see the memory_corruption_check_size and
+ memory_corruption_check_period parameters in
+ Documentation/kernel-parameters.txt to adjust this.
+
+ When enabled with the default parameters, this option has
+ almost no overhead, as it reserves a relatively small amount
+ of memory and scans it infrequently. It both detects corruption
+ and prevents it from affecting the running system.
+
+ It is, however, intended as a diagnostic tool; if repeatable
+ BIOS-originated corruption always affects the same memory,
+ you can use memmap= to prevent the kernel from using that
+ memory.
+
+config X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK
+ bool "Set the default setting of memory_corruption_check"
+ depends on X86_CHECK_BIOS_CORRUPTION
+ default y
+ ---help---
+ Set whether the default state of memory_corruption_check is
+ on or off.
+
+config X86_RESERVE_LOW
+ int "Amount of low memory, in kilobytes, to reserve for the BIOS"
+ default 64
+ range 4 640
+ ---help---
+ Specify the amount of low memory to reserve for the BIOS.
+
+ The first page contains BIOS data structures that the kernel
+ must not use, so that page must always be reserved.
+
+ By default we reserve the first 64K of physical RAM, as a
+ number of BIOSes are known to corrupt that memory range
+ during events such as suspend/resume or monitor cable
+ insertion, so it must not be used by the kernel.
+
+ You can set this to 4 if you are absolutely sure that you
+ trust the BIOS to get all its memory reservations and usages
+ right. If you know your BIOS have problems beyond the
+ default 64K area, you can set this to 640 to avoid using the
+ entire low memory range.
+
+ If you have doubts about the BIOS (e.g. suspend/resume does
+ not work or there's kernel crashes after certain hardware
+ hotplug events) then you might want to enable
+ X86_CHECK_BIOS_CORRUPTION=y to allow the kernel to check
+ typical corruption patterns.
+
+ Leave this to the default value of 64 if you are unsure.
+
+config X86_SUPPORTS_MEMORY_FAILURE
+ def_bool y
+ # MCE code calls memory_failure():
+ depends on X86_MCE
+ # On 32-bit this adds too big of NODES_SHIFT and we run out of page flags:
+ depends on !X86_NUMAQ
+ # On 32-bit SPARSEMEM adds too big of SECTIONS_WIDTH:
+ depends on X86_64 || !SPARSEMEM
+ select ARCH_SUPPORTS_MEMORY_FAILURE
+
+endmenu # Memory and NUMA Options
+
if X86_WANT_INTEL_MID
config X86_INTEL_MID
@@ -370,16 +587,6 @@ config X86_INTEL_LPSS
things like clock tree (common clock framework) and pincontrol
which are needed by the LPSS peripheral drivers.
-config X86_SUPPORTS_MEMORY_FAILURE
- def_bool y
- # MCE code calls memory_failure():
- depends on X86_MCE
- # On 32-bit this adds too big of NODES_SHIFT and we run out of page flags:
- depends on !X86_NUMAQ
- # On 32-bit SPARSEMEM adds too big of SECTIONS_WIDTH:
- depends on X86_64 || !SPARSEMEM
- select ARCH_SUPPORTS_MEMORY_FAILURE
-
config X86_VISWS
bool "SGI 320/540 (Visual Workstation)"
depends on X86_32 && PCI && X86_MPPARSE && PCI_GODIRECT
@@ -1091,209 +1298,6 @@ config ARCH_DMA_ADDR_T_64BIT
def_bool y
depends on X86_64 || HIGHMEM64G
-config DIRECT_GBPAGES
- bool "Enable 1GB pages for kernel pagetables" if EXPERT
- default y
- depends on X86_64
- ---help---
- Allow the kernel linear mapping to use 1GB pages on CPUs that
- support it. This can improve the kernel's performance a tiny bit by
- reducing TLB pressure. If in doubt, say "Y".
-
-# Common NUMA Features
-config NUMA
- bool "Numa Memory Allocation and Scheduler Support"
- depends on SMP
- depends on X86_64 || (X86_32 && HIGHMEM64G && (X86_NUMAQ || X86_BIGSMP || X86_SUMMIT && ACPI))
- default y if (X86_NUMAQ || X86_SUMMIT || X86_BIGSMP)
- ---help---
- Enable NUMA (Non Uniform Memory Access) support.
-
- The kernel will try to allocate memory used by a CPU on the
- local memory controller of the CPU and add some more
- NUMA awareness to the kernel.
-
- For 64-bit this is recommended if the system is Intel Core i7
- (or later), AMD Opteron, or EM64T NUMA.
-
- For 32-bit this is only needed on (rare) 32-bit-only platforms
- that support NUMA topologies, such as NUMAQ / Summit, or if you
- boot a 32-bit kernel on a 64-bit NUMA platform.
-
- Otherwise, you should say N.
-
-comment "NUMA (Summit) requires SMP, 64GB highmem support, ACPI"
- depends on X86_32 && X86_SUMMIT && (!HIGHMEM64G || !ACPI)
-
-config AMD_NUMA
- def_bool y
- prompt "Old style AMD Opteron NUMA detection"
- depends on X86_64 && NUMA && PCI
- ---help---
- Enable AMD NUMA node topology detection. You should say Y here if
- you have a multi processor AMD system. This uses an old method to
- read the NUMA configuration directly from the builtin Northbridge
- of Opteron. It is recommended to use X86_64_ACPI_NUMA instead,
- which also takes priority if both are compiled in.
-
-config X86_64_ACPI_NUMA
- def_bool y
- prompt "ACPI NUMA detection"
- depends on X86_64 && NUMA && ACPI && PCI
- select ACPI_NUMA
- ---help---
- Enable ACPI SRAT based node topology detection.
-
-# Some NUMA nodes have memory ranges that span
-# other nodes. Even though a pfn is valid and
-# between a node's start and end pfns, it may not
-# reside on that node. See memmap_init_zone()
-# for details.
-config NODES_SPAN_OTHER_NODES
- def_bool y
- depends on X86_64_ACPI_NUMA
-
-config NUMA_EMU
- bool "NUMA emulation"
- depends on NUMA
- ---help---
- Enable NUMA emulation. A flat machine will be split
- into virtual nodes when booted with "numa=fake=N", where N is the
- number of nodes. This is only useful for debugging.
-
-config NODES_SHIFT
- int "Maximum NUMA Nodes (as a power of 2)" if !MAXSMP
- range 1 10
- default "10" if MAXSMP
- default "6" if X86_64
- default "4" if X86_NUMAQ
- default "3"
- depends on NEED_MULTIPLE_NODES
- ---help---
- Specify the maximum number of NUMA Nodes available on the target
- system. Increases memory reserved to accommodate various tables.
-
-config ARCH_HAVE_MEMORY_PRESENT
- def_bool y
- depends on X86_32 && DISCONTIGMEM
-
-config NEED_NODE_MEMMAP_SIZE
- def_bool y
- depends on X86_32 && (DISCONTIGMEM || SPARSEMEM)
-
-config ARCH_FLATMEM_ENABLE
- def_bool y
- depends on X86_32 && !NUMA
-
-config ARCH_DISCONTIGMEM_ENABLE
- def_bool y
- depends on NUMA && X86_32
-
-config ARCH_DISCONTIGMEM_DEFAULT
- def_bool y
- depends on NUMA && X86_32
-
-config ARCH_SPARSEMEM_ENABLE
- def_bool y
- depends on X86_64 || NUMA || X86_32 || X86_32_NON_STANDARD
- select SPARSEMEM_STATIC if X86_32
- select SPARSEMEM_VMEMMAP_ENABLE if X86_64
-
-config ARCH_SPARSEMEM_DEFAULT
- def_bool y
- depends on X86_64
-
-config ARCH_SELECT_MEMORY_MODEL
- def_bool y
- depends on ARCH_SPARSEMEM_ENABLE
-
-config ARCH_MEMORY_PROBE
- bool "Enable sysfs memory/probe interface"
- depends on X86_64 && MEMORY_HOTPLUG
- help
- This option enables a sysfs memory/probe interface for testing.
- See Documentation/memory-hotplug.txt for more information.
- If you are unsure how to answer this question, answer N.
-
-config ARCH_PROC_KCORE_TEXT
- def_bool y
- depends on X86_64 && PROC_KCORE
-
-config ILLEGAL_POINTER_VALUE
- hex
- default 0 if X86_32
- default 0xdead000000000000 if X86_64
-
-source "mm/Kconfig"
-
-config HIGHPTE
- bool "Allocate 3rd-level pagetables from highmem"
- depends on HIGHMEM
- ---help---
- The VM uses one page table entry for each page of physical memory.
- For systems with a lot of RAM, this can be wasteful of precious
- low memory. Setting this option will put user-space page table
- entries in high memory.
-
-config X86_CHECK_BIOS_CORRUPTION
- bool "Check for low memory corruption"
- ---help---
- Periodically check for memory corruption in low memory, which
- is suspected to be caused by BIOS. Even when enabled in the
- configuration, it is disabled at runtime. Enable it by
- setting "memory_corruption_check=1" on the kernel command
- line. By default it scans the low 64k of memory every 60
- seconds; see the memory_corruption_check_size and
- memory_corruption_check_period parameters in
- Documentation/kernel-parameters.txt to adjust this.
-
- When enabled with the default parameters, this option has
- almost no overhead, as it reserves a relatively small amount
- of memory and scans it infrequently. It both detects corruption
- and prevents it from affecting the running system.
-
- It is, however, intended as a diagnostic tool; if repeatable
- BIOS-originated corruption always affects the same memory,
- you can use memmap= to prevent the kernel from using that
- memory.
-
-config X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK
- bool "Set the default setting of memory_corruption_check"
- depends on X86_CHECK_BIOS_CORRUPTION
- default y
- ---help---
- Set whether the default state of memory_corruption_check is
- on or off.
-
-config X86_RESERVE_LOW
- int "Amount of low memory, in kilobytes, to reserve for the BIOS"
- default 64
- range 4 640
- ---help---
- Specify the amount of low memory to reserve for the BIOS.
-
- The first page contains BIOS data structures that the kernel
- must not use, so that page must always be reserved.
-
- By default we reserve the first 64K of physical RAM, as a
- number of BIOSes are known to corrupt that memory range
- during events such as suspend/resume or monitor cable
- insertion, so it must not be used by the kernel.
-
- You can set this to 4 if you are absolutely sure that you
- trust the BIOS to get all its memory reservations and usages
- right. If you know your BIOS have problems beyond the
- default 64K area, you can set this to 640 to avoid using the
- entire low memory range.
-
- If you have doubts about the BIOS (e.g. suspend/resume does
- not work or there's kernel crashes after certain hardware
- hotplug events) then you might want to enable
- X86_CHECK_BIOS_CORRUPTION=y to allow the kernel to check
- typical corruption patterns.
-
- Leave this to the default value of 64 if you are unsure.
-
config MATH_EMULATION
bool
prompt "Math emulation" if X86_32
_
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 03/12] x86 Kconfig: move highmem
2014-01-13 19:22 [PATCH 00/12] [v2] Reorganize x86 Kconfig menu Dave Hansen
2014-01-13 19:22 ` [PATCH 01/12] x86 Kconfig: create extended platforms menu Dave Hansen
2014-01-13 19:22 ` [PATCH 02/12] x86 Kconfig: memory options Dave Hansen
@ 2014-01-13 19:22 ` Dave Hansen
2014-01-13 19:22 ` [PATCH 04/12] x86 Kconfig: processor options menu Dave Hansen
` (9 subsequent siblings)
12 siblings, 0 replies; 19+ messages in thread
From: Dave Hansen @ 2014-01-13 19:22 UTC (permalink / raw)
To: linux-kernel; +Cc: x86, Dave Hansen
From: Dave Hansen <dave.hansen@linux.intel.com>
This just continues to move things under the Memory and NUMA
Options menu, breaking it up a bit to make the patches easier to
audit.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
---
linux.git-davehans/arch/x86/Kconfig | 248 ++++++++++++++++++------------------
1 file changed, 124 insertions(+), 124 deletions(-)
diff -puN arch/x86/Kconfig~x86-config-move-highmem arch/x86/Kconfig
--- linux.git/arch/x86/Kconfig~x86-config-move-highmem 2014-01-13 11:11:34.925179358 -0800
+++ linux.git-davehans/arch/x86/Kconfig 2014-01-13 11:11:34.928179494 -0800
@@ -546,6 +546,130 @@ config X86_SUPPORTS_MEMORY_FAILURE
depends on X86_64 || !SPARSEMEM
select ARCH_SUPPORTS_MEMORY_FAILURE
+choice
+ prompt "High Memory Support"
+ default HIGHMEM64G if X86_NUMAQ
+ default HIGHMEM4G
+ depends on X86_32
+
+config NOHIGHMEM
+ bool "off"
+ depends on !X86_NUMAQ
+ ---help---
+ Linux can use up to 64 Gigabytes of physical memory on x86 systems.
+ However, the address space of 32-bit x86 processors is only 4
+ Gigabytes large. That means that, if you have a large amount of
+ physical memory, not all of it can be "permanently mapped" by the
+ kernel. The physical memory that's not permanently mapped is called
+ "high memory".
+
+ If you are compiling a kernel which will never run on a machine with
+ more than 1 Gigabyte total physical RAM, answer "off" here (default
+ choice and suitable for most users). This will result in a "3GB/1GB"
+ split: 3GB are mapped so that each process sees a 3GB virtual memory
+ space and the remaining part of the 4GB virtual memory space is used
+ by the kernel to permanently map as much physical memory as
+ possible.
+
+ If the machine has between 1 and 4 Gigabytes physical RAM, then
+ answer "4GB" here.
+
+ If more than 4 Gigabytes is used then answer "64GB" here. This
+ selection turns Intel PAE (Physical Address Extension) mode on.
+ PAE implements 3-level paging on IA32 processors. PAE is fully
+ supported by Linux, PAE mode is implemented on all recent Intel
+ processors (Pentium Pro and better). NOTE: If you say "64GB" here,
+ then the kernel will not boot on CPUs that don't support PAE!
+
+ The actual amount of total physical memory will either be
+ auto detected or can be forced by using a kernel command line option
+ such as "mem=256M". (Try "man bootparam" or see the documentation of
+ your boot loader (lilo or loadlin) about how to pass options to the
+ kernel at boot time.)
+
+ If unsure, say "off".
+
+config HIGHMEM4G
+ bool "4GB"
+ depends on !X86_NUMAQ
+ ---help---
+ Select this if you have a 32-bit processor and between 1 and 4
+ gigabytes of physical RAM.
+
+config HIGHMEM64G
+ bool "64GB"
+ depends on !M486
+ select X86_PAE
+ ---help---
+ Select this if you have a 32-bit processor and more than 4
+ gigabytes of physical RAM.
+
+endchoice
+
+choice
+ prompt "Memory split" if EXPERT
+ default VMSPLIT_3G
+ depends on X86_32
+ ---help---
+ Select the desired split between kernel and user memory.
+
+ If the address range available to the kernel is less than the
+ physical memory installed, the remaining memory will be available
+ as "high memory". Accessing high memory is a little more costly
+ than low memory, as it needs to be mapped into the kernel first.
+ Note that increasing the kernel address space limits the range
+ available to user programs, making the address space there
+ tighter. Selecting anything other than the default 3G/1G split
+ will also likely make your kernel incompatible with binary-only
+ kernel modules.
+
+ If you are not absolutely sure what you are doing, leave this
+ option alone!
+
+ config VMSPLIT_3G
+ bool "3G/1G user/kernel split"
+ config VMSPLIT_3G_OPT
+ depends on !X86_PAE
+ bool "3G/1G user/kernel split (for full 1G low memory)"
+ config VMSPLIT_2G
+ bool "2G/2G user/kernel split"
+ config VMSPLIT_2G_OPT
+ depends on !X86_PAE
+ bool "2G/2G user/kernel split (for full 2G low memory)"
+ config VMSPLIT_1G
+ bool "1G/3G user/kernel split"
+endchoice
+
+config PAGE_OFFSET
+ hex
+ default 0xB0000000 if VMSPLIT_3G_OPT
+ default 0x80000000 if VMSPLIT_2G
+ default 0x78000000 if VMSPLIT_2G_OPT
+ default 0x40000000 if VMSPLIT_1G
+ default 0xC0000000
+ depends on X86_32
+
+config HIGHMEM
+ def_bool y
+ depends on X86_32 && (HIGHMEM64G || HIGHMEM4G)
+
+config X86_PAE
+ bool "PAE (Physical Address Extension) Support"
+ depends on X86_32 && !HIGHMEM4G
+ ---help---
+ PAE is required for NX support, and furthermore enables
+ larger swapspace support for non-overcommit purposes. It
+ has the cost of more pagetable lookup overhead, and also
+ consumes more pagetable space per process.
+
+config ARCH_PHYS_ADDR_T_64BIT
+ def_bool y
+ depends on X86_64 || X86_PAE
+
+config ARCH_DMA_ADDR_T_64BIT
+ def_bool y
+ depends on X86_64 || HIGHMEM64G
+
endmenu # Memory and NUMA Options
if X86_WANT_INTEL_MID
@@ -1174,130 +1298,6 @@ config X86_CPUID
with major 203 and minors 0 to 31 for /dev/cpu/0/cpuid to
/dev/cpu/31/cpuid.
-choice
- prompt "High Memory Support"
- default HIGHMEM64G if X86_NUMAQ
- default HIGHMEM4G
- depends on X86_32
-
-config NOHIGHMEM
- bool "off"
- depends on !X86_NUMAQ
- ---help---
- Linux can use up to 64 Gigabytes of physical memory on x86 systems.
- However, the address space of 32-bit x86 processors is only 4
- Gigabytes large. That means that, if you have a large amount of
- physical memory, not all of it can be "permanently mapped" by the
- kernel. The physical memory that's not permanently mapped is called
- "high memory".
-
- If you are compiling a kernel which will never run on a machine with
- more than 1 Gigabyte total physical RAM, answer "off" here (default
- choice and suitable for most users). This will result in a "3GB/1GB"
- split: 3GB are mapped so that each process sees a 3GB virtual memory
- space and the remaining part of the 4GB virtual memory space is used
- by the kernel to permanently map as much physical memory as
- possible.
-
- If the machine has between 1 and 4 Gigabytes physical RAM, then
- answer "4GB" here.
-
- If more than 4 Gigabytes is used then answer "64GB" here. This
- selection turns Intel PAE (Physical Address Extension) mode on.
- PAE implements 3-level paging on IA32 processors. PAE is fully
- supported by Linux, PAE mode is implemented on all recent Intel
- processors (Pentium Pro and better). NOTE: If you say "64GB" here,
- then the kernel will not boot on CPUs that don't support PAE!
-
- The actual amount of total physical memory will either be
- auto detected or can be forced by using a kernel command line option
- such as "mem=256M". (Try "man bootparam" or see the documentation of
- your boot loader (lilo or loadlin) about how to pass options to the
- kernel at boot time.)
-
- If unsure, say "off".
-
-config HIGHMEM4G
- bool "4GB"
- depends on !X86_NUMAQ
- ---help---
- Select this if you have a 32-bit processor and between 1 and 4
- gigabytes of physical RAM.
-
-config HIGHMEM64G
- bool "64GB"
- depends on !M486
- select X86_PAE
- ---help---
- Select this if you have a 32-bit processor and more than 4
- gigabytes of physical RAM.
-
-endchoice
-
-choice
- prompt "Memory split" if EXPERT
- default VMSPLIT_3G
- depends on X86_32
- ---help---
- Select the desired split between kernel and user memory.
-
- If the address range available to the kernel is less than the
- physical memory installed, the remaining memory will be available
- as "high memory". Accessing high memory is a little more costly
- than low memory, as it needs to be mapped into the kernel first.
- Note that increasing the kernel address space limits the range
- available to user programs, making the address space there
- tighter. Selecting anything other than the default 3G/1G split
- will also likely make your kernel incompatible with binary-only
- kernel modules.
-
- If you are not absolutely sure what you are doing, leave this
- option alone!
-
- config VMSPLIT_3G
- bool "3G/1G user/kernel split"
- config VMSPLIT_3G_OPT
- depends on !X86_PAE
- bool "3G/1G user/kernel split (for full 1G low memory)"
- config VMSPLIT_2G
- bool "2G/2G user/kernel split"
- config VMSPLIT_2G_OPT
- depends on !X86_PAE
- bool "2G/2G user/kernel split (for full 2G low memory)"
- config VMSPLIT_1G
- bool "1G/3G user/kernel split"
-endchoice
-
-config PAGE_OFFSET
- hex
- default 0xB0000000 if VMSPLIT_3G_OPT
- default 0x80000000 if VMSPLIT_2G
- default 0x78000000 if VMSPLIT_2G_OPT
- default 0x40000000 if VMSPLIT_1G
- default 0xC0000000
- depends on X86_32
-
-config HIGHMEM
- def_bool y
- depends on X86_32 && (HIGHMEM64G || HIGHMEM4G)
-
-config X86_PAE
- bool "PAE (Physical Address Extension) Support"
- depends on X86_32 && !HIGHMEM4G
- ---help---
- PAE is required for NX support, and furthermore enables
- larger swapspace support for non-overcommit purposes. It
- has the cost of more pagetable lookup overhead, and also
- consumes more pagetable space per process.
-
-config ARCH_PHYS_ADDR_T_64BIT
- def_bool y
- depends on X86_64 || X86_PAE
-
-config ARCH_DMA_ADDR_T_64BIT
- def_bool y
- depends on X86_64 || HIGHMEM64G
-
config MATH_EMULATION
bool
prompt "Math emulation" if X86_32
_
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 04/12] x86 Kconfig: processor options menu
2014-01-13 19:22 [PATCH 00/12] [v2] Reorganize x86 Kconfig menu Dave Hansen
` (2 preceding siblings ...)
2014-01-13 19:22 ` [PATCH 03/12] x86 Kconfig: move highmem Dave Hansen
@ 2014-01-13 19:22 ` Dave Hansen
2014-01-13 19:22 ` [PATCH 05/12] x86 Kconfig: processor drivers Dave Hansen
` (8 subsequent siblings)
12 siblings, 0 replies; 19+ messages in thread
From: Dave Hansen @ 2014-01-13 19:22 UTC (permalink / raw)
To: linux-kernel; +Cc: x86, Dave Hansen
From: Dave Hansen <dave.hansen@linux.intel.com>
This tries to consolidate the actual processor options that
someone might want to configure. It's a bit arbitrary how you
might separate these, but I at least took a stab at it.
The real goal here was to hide stuff that folks will rarely look
at, and to make them easier to find when folks _do_ need to
change them.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
---
linux.git-davehans/arch/x86/Kconfig | 208 ++++++++++++++++++------------------
1 file changed, 106 insertions(+), 102 deletions(-)
diff -puN arch/x86/Kconfig~processor-options arch/x86/Kconfig
--- linux.git/arch/x86/Kconfig~processor-options 2014-01-13 11:11:35.138188988 -0800
+++ linux.git-davehans/arch/x86/Kconfig 2014-01-13 11:11:35.141189123 -0800
@@ -264,6 +264,8 @@ source "kernel/Kconfig.freezer"
menu "Processor type and features"
+menu "Processor Options and Features"
+
config SMP
bool "Symmetric multi-processing support"
---help---
@@ -292,6 +294,110 @@ config SMP
If you don't know what to do here, say N.
+config MAXSMP
+ bool "Enable Maximum number of SMP Processors and NUMA Nodes"
+ depends on X86_64 && SMP && DEBUG_KERNEL
+ select CPUMASK_OFFSTACK
+ ---help---
+ Enable maximum number of CPUS and NUMA Nodes for this architecture.
+ If unsure, say N.
+
+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 && !CPUMASK_OFFSTACK
+ range 2 8192 if SMP && !MAXSMP && CPUMASK_OFFSTACK && X86_64
+ default "1" if !SMP
+ default "8192" if MAXSMP
+ default "32" if SMP && (X86_NUMAQ || X86_SUMMIT || X86_BIGSMP || X86_ES7000)
+ default "8" if SMP
+ ---help---
+ This allows you to specify the maximum number of CPUs which this
+ kernel will support. If CPUMASK_OFFSTACK is enabled, the maximum
+ supported value is 4096, otherwise the maximum value is 512. The
+ minimum value which makes sense is 2.
+
+ This is purely to save memory - each supported CPU adds
+ approximately eight kilobytes to the kernel image.
+
+config HOTPLUG_CPU
+ bool "Support for hot-pluggable CPUs"
+ depends on SMP
+ ---help---
+ Say Y here to allow turning CPUs off and on. CPUs can be
+ controlled through /sys/devices/system/cpu.
+ ( Note: power management support will enable this option
+ automatically on SMP systems. )
+ Say N if you want to disable CPU hotplug.
+
+config BOOTPARAM_HOTPLUG_CPU0
+ bool "Set default setting of cpu0_hotpluggable"
+ default n
+ depends on HOTPLUG_CPU
+ ---help---
+ Set whether default state of cpu0_hotpluggable is on or off.
+
+ Say Y here to enable CPU0 hotplug by default. If this switch
+ is turned on, there is no need to give cpu0_hotplug kernel
+ parameter and the CPU0 hotplug feature is enabled by default.
+
+ Please note: there are two known CPU0 dependencies if you want
+ to enable the CPU0 hotplug feature either by this switch or by
+ cpu0_hotplug kernel parameter.
+
+ First, resume from hibernate or suspend always starts from CPU0.
+ So hibernate and suspend are prevented if CPU0 is offline.
+
+ Second dependency is PIC interrupts always go to CPU0. CPU0 can not
+ offline if any interrupt can not migrate out of CPU0. There may
+ be other CPU0 dependencies.
+
+ Please make sure the dependencies are under your control before
+ you enable this feature.
+
+ Say N if you don't want to enable CPU0 hotplug feature by default.
+ You still can enable the CPU0 hotplug feature at boot by kernel
+ parameter cpu0_hotplug.
+
+config DEBUG_HOTPLUG_CPU0
+ def_bool n
+ prompt "Debug CPU0 hotplug"
+ depends on HOTPLUG_CPU
+ ---help---
+ Enabling this option offlines CPU0 (if CPU0 can be offlined) as
+ soon as possible and boots up userspace with CPU0 offlined. User
+ can online CPU0 back after boot time.
+
+ To debug CPU0 hotplug, you need to enable CPU0 offline/online
+ feature by either turning on CONFIG_BOOTPARAM_HOTPLUG_CPU0 during
+ compilation or giving cpu0_hotplug kernel parameter at boot.
+
+ If unsure, say N.
+
+source "arch/x86/Kconfig.cpu"
+
+config ARCH_RANDOM
+ def_bool y
+ prompt "x86 architectural random number generator" if EXPERT
+ ---help---
+ Enable the x86 architectural RDRAND instruction
+ (Intel Bull Mountain technology) to generate random numbers.
+ If supported, this is a high bandwidth, cryptographically
+ secure hardware random number generator.
+
+config X86_SMAP
+ def_bool y
+ prompt "Supervisor Mode Access Prevention" if EXPERT
+ ---help---
+ Supervisor Mode Access Prevention (SMAP) is a security
+ feature in newer Intel processors. There is a small
+ performance cost if this enabled and turned on; there is
+ also a small increase in the kernel size if this is enabled.
+
+ If unsure, say Y.
+
+endmenu # Processor Options
+
config X86_X2APIC
bool "Support x2apic"
depends on X86_LOCAL_APIC && X86_64 && IRQ_REMAP
@@ -884,8 +990,6 @@ config X86_CYCLONE_TIMER
def_bool y
depends on X86_SUMMIT
-source "arch/x86/Kconfig.cpu"
-
config HPET_TIMER
def_bool X86_64
prompt "HPET Timer Support" if X86_32
@@ -996,32 +1100,6 @@ config IOMMU_HELPER
def_bool y
depends on CALGARY_IOMMU || GART_IOMMU || SWIOTLB || AMD_IOMMU
-config MAXSMP
- bool "Enable Maximum number of SMP Processors and NUMA Nodes"
- depends on X86_64 && SMP && DEBUG_KERNEL
- select CPUMASK_OFFSTACK
- ---help---
- Enable maximum number of CPUS and NUMA Nodes for this architecture.
- If unsure, say N.
-
-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 && !CPUMASK_OFFSTACK
- range 2 8192 if SMP && !MAXSMP && CPUMASK_OFFSTACK && X86_64
- default "1" if !SMP
- default "8192" if MAXSMP
- default "32" if SMP && (X86_NUMAQ || X86_SUMMIT || X86_BIGSMP || X86_ES7000)
- default "8" if SMP
- ---help---
- This allows you to specify the maximum number of CPUs which this
- kernel will support. If CPUMASK_OFFSTACK is enabled, the maximum
- supported value is 4096, otherwise the maximum value is 512. The
- minimum value which makes sense is 2.
-
- This is purely to save memory - each supported CPU adds
- approximately eight kilobytes to the kernel image.
-
config SCHED_SMT
bool "SMT (Hyperthreading) scheduler support"
depends on X86_HT
@@ -1409,26 +1487,6 @@ config ARCH_USES_PG_UNCACHED
def_bool y
depends on X86_PAT
-config ARCH_RANDOM
- def_bool y
- prompt "x86 architectural random number generator" if EXPERT
- ---help---
- Enable the x86 architectural RDRAND instruction
- (Intel Bull Mountain technology) to generate random numbers.
- If supported, this is a high bandwidth, cryptographically
- secure hardware random number generator.
-
-config X86_SMAP
- def_bool y
- prompt "Supervisor Mode Access Prevention" if EXPERT
- ---help---
- Supervisor Mode Access Prevention (SMAP) is a security
- feature in newer Intel processors. There is a small
- performance cost if this enabled and turned on; there is
- also a small increase in the kernel size if this is enabled.
-
- If unsure, say Y.
-
config EFI
bool "EFI runtime service support"
depends on ACPI
@@ -1614,60 +1672,6 @@ config PHYSICAL_ALIGN
Don't change this unless you know what you are doing.
-config HOTPLUG_CPU
- bool "Support for hot-pluggable CPUs"
- depends on SMP
- ---help---
- Say Y here to allow turning CPUs off and on. CPUs can be
- controlled through /sys/devices/system/cpu.
- ( Note: power management support will enable this option
- automatically on SMP systems. )
- Say N if you want to disable CPU hotplug.
-
-config BOOTPARAM_HOTPLUG_CPU0
- bool "Set default setting of cpu0_hotpluggable"
- default n
- depends on HOTPLUG_CPU
- ---help---
- Set whether default state of cpu0_hotpluggable is on or off.
-
- Say Y here to enable CPU0 hotplug by default. If this switch
- is turned on, there is no need to give cpu0_hotplug kernel
- parameter and the CPU0 hotplug feature is enabled by default.
-
- Please note: there are two known CPU0 dependencies if you want
- to enable the CPU0 hotplug feature either by this switch or by
- cpu0_hotplug kernel parameter.
-
- First, resume from hibernate or suspend always starts from CPU0.
- So hibernate and suspend are prevented if CPU0 is offline.
-
- Second dependency is PIC interrupts always go to CPU0. CPU0 can not
- offline if any interrupt can not migrate out of CPU0. There may
- be other CPU0 dependencies.
-
- Please make sure the dependencies are under your control before
- you enable this feature.
-
- Say N if you don't want to enable CPU0 hotplug feature by default.
- You still can enable the CPU0 hotplug feature at boot by kernel
- parameter cpu0_hotplug.
-
-config DEBUG_HOTPLUG_CPU0
- def_bool n
- prompt "Debug CPU0 hotplug"
- depends on HOTPLUG_CPU
- ---help---
- Enabling this option offlines CPU0 (if CPU0 can be offlined) as
- soon as possible and boots up userspace with CPU0 offlined. User
- can online CPU0 back after boot time.
-
- To debug CPU0 hotplug, you need to enable CPU0 offline/online
- feature by either turning on CONFIG_BOOTPARAM_HOTPLUG_CPU0 during
- compilation or giving cpu0_hotplug kernel parameter at boot.
-
- If unsure, say N.
-
config COMPAT_VDSO
def_bool y
prompt "Compat VDSO support"
_
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 05/12] x86 Kconfig: processor drivers
2014-01-13 19:22 [PATCH 00/12] [v2] Reorganize x86 Kconfig menu Dave Hansen
` (3 preceding siblings ...)
2014-01-13 19:22 ` [PATCH 04/12] x86 Kconfig: processor options menu Dave Hansen
@ 2014-01-13 19:22 ` Dave Hansen
2014-01-13 19:22 ` [PATCH 06/12] x86 Kconfig: scheduler options Dave Hansen
` (7 subsequent siblings)
12 siblings, 0 replies; 19+ messages in thread
From: Dave Hansen @ 2014-01-13 19:22 UTC (permalink / raw)
To: linux-kernel; +Cc: x86, Dave Hansen
From: Dave Hansen <dave.hansen@linux.intel.com>
These are both drivers to access very cpu and arch-specific
features. However, they are probably not very commonly changed
in the configuration. Give them their own menu.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
---
linux.git-davehans/arch/x86/Kconfig | 169 ++++++++++++++++++------------------
1 file changed, 86 insertions(+), 83 deletions(-)
diff -puN arch/x86/Kconfig~processor-drivers arch/x86/Kconfig
--- linux.git/arch/x86/Kconfig~processor-drivers 2014-01-13 11:11:35.346198391 -0800
+++ linux.git-davehans/arch/x86/Kconfig 2014-01-13 11:11:35.348198482 -0800
@@ -396,6 +396,92 @@ config X86_SMAP
If unsure, say Y.
+comment "Processor Feature Drivers"
+
+config MICROCODE
+ tristate "CPU microcode loading support"
+ depends on CPU_SUP_AMD || CPU_SUP_INTEL
+ select FW_LOADER
+ ---help---
+
+ If you say Y here, you will be able to update the microcode on
+ certain Intel and AMD processors. The Intel support is for the
+ IA32 family, e.g. Pentium Pro, Pentium II, Pentium III, Pentium 4,
+ Xeon etc. The AMD support is for families 0x10 and later. You will
+ obviously need the actual microcode binary data itself which is not
+ shipped with the Linux kernel.
+
+ This option selects the general module only, you need to select
+ at least one vendor specific module as well.
+
+ To compile this driver as a module, choose M here: the module
+ will be called microcode.
+
+config MICROCODE_INTEL
+ bool "Intel microcode loading support"
+ depends on MICROCODE
+ default MICROCODE
+ select FW_LOADER
+ ---help---
+ This options enables microcode patch loading support for Intel
+ processors.
+
+ For latest news and information on obtaining all the required
+ Intel ingredients for this driver, check:
+ <http://www.urbanmyth.org/microcode/>.
+
+config MICROCODE_AMD
+ bool "AMD microcode loading support"
+ depends on MICROCODE
+ select FW_LOADER
+ ---help---
+ If you select this option, microcode patch loading support for AMD
+ processors will be enabled.
+
+config MICROCODE_OLD_INTERFACE
+ def_bool y
+ depends on MICROCODE
+
+config MICROCODE_INTEL_LIB
+ def_bool y
+ depends on MICROCODE_INTEL
+
+config MICROCODE_INTEL_EARLY
+ def_bool n
+
+config MICROCODE_AMD_EARLY
+ def_bool n
+
+config MICROCODE_EARLY
+ bool "Early load microcode"
+ depends on MICROCODE=y && BLK_DEV_INITRD
+ select MICROCODE_INTEL_EARLY if MICROCODE_INTEL
+ select MICROCODE_AMD_EARLY if MICROCODE_AMD
+ default y
+ help
+ This option provides functionality to read additional microcode data
+ at the beginning of initrd image. The data tells kernel to load
+ microcode to CPU's as early as possible. No functional change if no
+ microcode data is glued to the initrd, therefore it's safe to say Y.
+
+config X86_MSR
+ tristate "/dev/cpu/*/msr - Model-specific register support"
+ ---help---
+ This device gives privileged processes access to the x86
+ Model-Specific Registers (MSRs). It is a character device with
+ major 202 and minors 0 to 31 for /dev/cpu/0/msr to /dev/cpu/31/msr.
+ MSR accesses are directed to a specific CPU on multi-processor
+ systems.
+
+config X86_CPUID
+ tristate "/dev/cpu/*/cpuid - CPU information support"
+ ---help---
+ This device gives processes access to the x86 CPUID instruction to
+ be executed on a specific processor. It is a character device
+ with major 203 and minors 0 to 31 for /dev/cpu/0/cpuid to
+ /dev/cpu/31/cpuid.
+
+
endmenu # Processor Options
config X86_X2APIC
@@ -1293,89 +1379,6 @@ config X86_REBOOTFIXUPS
enable this option even if you don't need it.
Say N otherwise.
-config MICROCODE
- tristate "CPU microcode loading support"
- depends on CPU_SUP_AMD || CPU_SUP_INTEL
- select FW_LOADER
- ---help---
-
- If you say Y here, you will be able to update the microcode on
- certain Intel and AMD processors. The Intel support is for the
- IA32 family, e.g. Pentium Pro, Pentium II, Pentium III, Pentium 4,
- Xeon etc. The AMD support is for families 0x10 and later. You will
- obviously need the actual microcode binary data itself which is not
- shipped with the Linux kernel.
-
- This option selects the general module only, you need to select
- at least one vendor specific module as well.
-
- To compile this driver as a module, choose M here: the module
- will be called microcode.
-
-config MICROCODE_INTEL
- bool "Intel microcode loading support"
- depends on MICROCODE
- default MICROCODE
- select FW_LOADER
- ---help---
- This options enables microcode patch loading support for Intel
- processors.
-
- For latest news and information on obtaining all the required
- Intel ingredients for this driver, check:
- <http://www.urbanmyth.org/microcode/>.
-
-config MICROCODE_AMD
- bool "AMD microcode loading support"
- depends on MICROCODE
- select FW_LOADER
- ---help---
- If you select this option, microcode patch loading support for AMD
- processors will be enabled.
-
-config MICROCODE_OLD_INTERFACE
- def_bool y
- depends on MICROCODE
-
-config MICROCODE_INTEL_LIB
- def_bool y
- depends on MICROCODE_INTEL
-
-config MICROCODE_INTEL_EARLY
- def_bool n
-
-config MICROCODE_AMD_EARLY
- def_bool n
-
-config MICROCODE_EARLY
- bool "Early load microcode"
- depends on MICROCODE=y && BLK_DEV_INITRD
- select MICROCODE_INTEL_EARLY if MICROCODE_INTEL
- select MICROCODE_AMD_EARLY if MICROCODE_AMD
- default y
- help
- This option provides functionality to read additional microcode data
- at the beginning of initrd image. The data tells kernel to load
- microcode to CPU's as early as possible. No functional change if no
- microcode data is glued to the initrd, therefore it's safe to say Y.
-
-config X86_MSR
- tristate "/dev/cpu/*/msr - Model-specific register support"
- ---help---
- This device gives privileged processes access to the x86
- Model-Specific Registers (MSRs). It is a character device with
- major 202 and minors 0 to 31 for /dev/cpu/0/msr to /dev/cpu/31/msr.
- MSR accesses are directed to a specific CPU on multi-processor
- systems.
-
-config X86_CPUID
- tristate "/dev/cpu/*/cpuid - CPU information support"
- ---help---
- This device gives processes access to the x86 CPUID instruction to
- be executed on a specific processor. It is a character device
- with major 203 and minors 0 to 31 for /dev/cpu/0/cpuid to
- /dev/cpu/31/cpuid.
-
config MATH_EMULATION
bool
prompt "Math emulation" if X86_32
_
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 06/12] x86 Kconfig: scheduler options
2014-01-13 19:22 [PATCH 00/12] [v2] Reorganize x86 Kconfig menu Dave Hansen
` (4 preceding siblings ...)
2014-01-13 19:22 ` [PATCH 05/12] x86 Kconfig: processor drivers Dave Hansen
@ 2014-01-13 19:22 ` Dave Hansen
2014-01-13 19:22 ` [PATCH 07/12] x86 Kconfig: move memtest Dave Hansen
` (6 subsequent siblings)
12 siblings, 0 replies; 19+ messages in thread
From: Dave Hansen @ 2014-01-13 19:22 UTC (permalink / raw)
To: linux-kernel; +Cc: x86, Dave Hansen
From: Dave Hansen <dave.hansen@linux.intel.com>
These are a few architecture-specific options that affect the
scheduler. Group them together.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
---
linux.git-davehans/arch/x86/Kconfig | 28 ++++++++++++++++------------
1 file changed, 16 insertions(+), 12 deletions(-)
diff -puN arch/x86/Kconfig~x86-scheduler-options arch/x86/Kconfig
--- linux.git/arch/x86/Kconfig~x86-scheduler-options 2014-01-13 11:11:35.553207750 -0800
+++ linux.git-davehans/arch/x86/Kconfig 2014-01-13 11:11:35.555207841 -0800
@@ -959,18 +959,6 @@ config X86_32_IRIS
If unused, say N.
-config SCHED_OMIT_FRAME_POINTER
- def_bool y
- prompt "Single-depth WCHAN output"
- depends on X86
- ---help---
- Calculate simpler /proc/<PID>/wchan values. If this option
- is disabled then wchan values will recurse back to the
- caller function. This provides more accurate wchan values,
- at the expense of slightly more scheduling overhead.
-
- If in doubt, say "Y".
-
menuconfig HYPERVISOR_GUEST
bool "Linux guest support"
---help---
@@ -1186,6 +1174,8 @@ config IOMMU_HELPER
def_bool y
depends on CALGARY_IOMMU || GART_IOMMU || SWIOTLB || AMD_IOMMU
+menu "x86 Scheduler Options"
+
config SCHED_SMT
bool "SMT (Hyperthreading) scheduler support"
depends on X86_HT
@@ -1204,6 +1194,20 @@ config SCHED_MC
making when dealing with multi-core CPU chips at a cost of slightly
increased overhead in some places. If unsure say N here.
+config SCHED_OMIT_FRAME_POINTER
+ def_bool y
+ prompt "Single-depth WCHAN output"
+ depends on X86
+ ---help---
+ Calculate simpler /proc/<PID>/wchan values. If this option
+ is disabled then wchan values will recurse back to the
+ caller function. This provides more accurate wchan values,
+ at the expense of slightly more scheduling overhead.
+
+ If in doubt, say "Y".
+
+endmenu # x86 Scheduler Options
+
source "kernel/Kconfig.preempt"
config X86_UP_APIC
_
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 07/12] x86 Kconfig: move memtest
2014-01-13 19:22 [PATCH 00/12] [v2] Reorganize x86 Kconfig menu Dave Hansen
` (5 preceding siblings ...)
2014-01-13 19:22 ` [PATCH 06/12] x86 Kconfig: scheduler options Dave Hansen
@ 2014-01-13 19:22 ` Dave Hansen
2014-01-13 19:22 ` [PATCH 08/12] x86 Kconfig: bury obscure options Dave Hansen
` (5 subsequent siblings)
12 siblings, 0 replies; 19+ messages in thread
From: Dave Hansen @ 2014-01-13 19:22 UTC (permalink / raw)
To: linux-kernel; +Cc: x86, Dave Hansen
From: Dave Hansen <dave.hansen@linux.intel.com>
Move the "Memtest" option over to the "Memory Debugging" menu.
The code is not x86 specific at all, but it still resides in
arch/x86, so keep the x86 dependency.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
---
linux.git-davehans/arch/x86/Kconfig | 11 -----------
linux.git-davehans/mm/Kconfig.debug | 12 ++++++++++++
2 files changed, 12 insertions(+), 11 deletions(-)
diff -puN arch/x86/Kconfig~move-memtest arch/x86/Kconfig
--- linux.git/arch/x86/Kconfig~move-memtest 2014-01-13 11:11:35.761217154 -0800
+++ linux.git-davehans/arch/x86/Kconfig 2014-01-13 11:11:35.764217289 -0800
@@ -1045,17 +1045,6 @@ endif #HYPERVISOR_GUEST
config NO_BOOTMEM
def_bool y
-config MEMTEST
- bool "Memtest"
- ---help---
- This option adds a kernel parameter 'memtest', which allows memtest
- to be set.
- memtest=0, mean disabled; -- default
- memtest=1, mean do 1 test pattern;
- ...
- memtest=4, mean do 4 test patterns.
- If you are unsure how to answer this question, answer N.
-
config X86_SUMMIT_NUMA
def_bool y
depends on X86_32 && NUMA && X86_32_NON_STANDARD
diff -puN mm/Kconfig.debug~move-memtest mm/Kconfig.debug
--- linux.git/mm/Kconfig.debug~move-memtest 2014-01-13 11:11:35.762217199 -0800
+++ linux.git-davehans/mm/Kconfig.debug 2014-01-13 11:11:35.765217335 -0800
@@ -1,3 +1,15 @@
+config MEMTEST
+ bool "Memtest"
+ depends on X86
+ ---help---
+ This option adds a kernel parameter 'memtest', which allows memtest
+ to be set.
+ memtest=0, mean disabled; -- default
+ memtest=1, mean do 1 test pattern;
+ ...
+ memtest=4, mean do 4 test patterns.
+ If you are unsure how to answer this question, answer N.
+
config DEBUG_PAGEALLOC
bool "Debug page memory allocations"
depends on DEBUG_KERNEL
_
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 08/12] x86 Kconfig: bury obscure options
2014-01-13 19:22 [PATCH 00/12] [v2] Reorganize x86 Kconfig menu Dave Hansen
` (6 preceding siblings ...)
2014-01-13 19:22 ` [PATCH 07/12] x86 Kconfig: move memtest Dave Hansen
@ 2014-01-13 19:22 ` Dave Hansen
2014-01-13 19:22 ` [PATCH 09/12] x86 Kconfig: create mtrr menu under processsor options Dave Hansen
` (4 subsequent siblings)
12 siblings, 0 replies; 19+ messages in thread
From: Dave Hansen @ 2014-01-13 19:22 UTC (permalink / raw)
To: linux-kernel; +Cc: x86, Dave Hansen
From: Dave Hansen <dave.hansen@linux.intel.com>
While I respect the fact that the owners of Dell Inspiron 8000s
have kept I8K compiling and "working" all these years, the URL
referenced contains a helpful README:
> This package is no longer maintained by me. I don't use it
> anymore and I'm not interested in maintaing it. Please DON'T
> SEND BUG REPORT OR PATCHES.
In other words, this is unmaintained code for a single
13-year-old model of a single vendor's laptop. I don't think
such an option deserves to have he same visibility as
"Preemption Model".
This patch creates an "Obscure x86 Options" menu, and sticks
it way at the bottom where we won't have to look at it. It moves
a few very obscure drivers and hardware feature in to there.
Here's how the menu looks now:
[*] Enable MPS table
[*] Enable DMI scanning
[*] Old AMD GART IOMMU support
[*] IBM Calgary IOMMU support
[*] Should Calgary be enabled by default? (NEW)
[*] Reroute for broken boot IRQs
<*> Dell laptop support
On 32-bit it also contains these:
[*] Enable VM86 support
< > Toshiba Laptop support
< > Eurobraille/Iris poweroff module
[ ] PentiumPro memory ordering errata workaround
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
---
linux.git-davehans/arch/x86/Kconfig | 321 ++++++++++++++++----------------
linux.git-davehans/arch/x86/Kconfig.cpu | 13 -
2 files changed, 169 insertions(+), 165 deletions(-)
diff -puN arch/x86/Kconfig~x86-mps-hide arch/x86/Kconfig
--- linux.git/arch/x86/Kconfig~x86-mps-hide 2014-01-13 11:11:35.976226874 -0800
+++ linux.git-davehans/arch/x86/Kconfig 2014-01-13 11:11:35.980227055 -0800
@@ -495,14 +495,6 @@ config X86_X2APIC
If you don't know what to do here, say N.
-config X86_MPPARSE
- bool "Enable MPS table" if ACPI || SFI
- default y
- depends on X86_LOCAL_APIC
- ---help---
- For old smp systems that do not have proper acpi support. Newer systems
- (esp with 64bit cpus) with acpi support, MADT and DSDT will override it
-
config X86_BIGSMP
bool "Support for big SMP systems with more than 8 CPUs"
depends on X86_32 && SMP
@@ -946,19 +938,6 @@ config X86_ES7000
Support for Unisys ES7000 systems. Say 'Y' here if this kernel is
supposed to run on an IA32-based Unisys ES7000 system.
-config X86_32_IRIS
- tristate "Eurobraille/Iris poweroff module"
- depends on X86_32
- ---help---
- The Iris machines from EuroBraille do not have APM or ACPI support
- to shut themselves down properly. A special I/O sequence is
- needed to do so, which is what this module does at
- kernel shutdown.
-
- This is only for Iris machines from EuroBraille.
-
- If unused, say N.
-
menuconfig HYPERVISOR_GUEST
bool "Linux guest support"
---help---
@@ -1088,67 +1067,6 @@ config APB_TIMER
as it is off-chip. APB timers are always running regardless of CPU
C states, they are used as per CPU clockevent device when possible.
-# Mark as expert because too many people got it wrong.
-# The code disables itself when not needed.
-config DMI
- default y
- bool "Enable DMI scanning" if EXPERT
- ---help---
- Enabled scanning of DMI to identify machine quirks. Say Y
- here unless you have verified that your setup is not
- affected by entries in the DMI blacklist. Required by PNP
- BIOS code.
-
-config GART_IOMMU
- bool "Old AMD GART IOMMU support"
- select SWIOTLB
- depends on X86_64 && PCI && AMD_NB
- ---help---
- Provides a driver for older AMD Athlon64/Opteron/Turion/Sempron
- GART based hardware IOMMUs.
-
- The GART supports full DMA access for devices with 32-bit access
- limitations, on systems with more than 3 GB. This is usually needed
- for USB, sound, many IDE/SATA chipsets and some other devices.
-
- Newer systems typically have a modern AMD IOMMU, supported via
- the CONFIG_AMD_IOMMU=y config option.
-
- In normal configurations this driver is only active when needed:
- there's more than 3 GB of memory and the system contains a
- 32-bit limited device.
-
- If unsure, say Y.
-
-config CALGARY_IOMMU
- bool "IBM Calgary IOMMU support"
- 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.
-
# need this always selected by IOMMU for the VIA workaround
config SWIOTLB
def_bool y if X86_64
@@ -1236,29 +1154,6 @@ config X86_VISWS_APIC
def_bool y
depends on X86_32 && X86_VISWS
-config X86_REROUTE_FOR_BROKEN_BOOT_IRQS
- bool "Reroute for broken boot IRQs"
- depends on X86_IO_APIC
- ---help---
- This option enables a workaround that fixes a source of
- spurious interrupts. This is recommended when threaded
- interrupt handling is used on systems where the generation of
- superfluous "boot interrupts" cannot be disabled.
-
- Some chipsets generate a legacy INTx "boot IRQ" when the IRQ
- entry in the chipset's IO-APIC is masked (as, e.g. the RT
- kernel does during interrupt handling). On chipsets where this
- boot IRQ generation cannot be disabled, this workaround keeps
- the original IRQ line masked so that only the equivalent "boot
- IRQ" is delivered to the CPUs. The workaround also tells the
- kernel to set up the IRQ handler on the boot IRQ line. In this
- way only one interrupt is delivered to the kernel. Otherwise
- the spurious second interrupt may cause the kernel to bring
- down (vital) interrupt lines.
-
- Only affects "broken" chipsets. Interrupt sharing may be
- increased on these systems.
-
config X86_MCE
bool "Machine Check / overheating reporting"
default y
@@ -1308,53 +1203,6 @@ config X86_THERMAL_VECTOR
def_bool y
depends on X86_MCE_INTEL
-config VM86
- bool "Enable VM86 support" if EXPERT
- default y
- depends on X86_32
- ---help---
- This option is required by programs like DOSEMU to run 16-bit legacy
- code on X86 processors. It also may be needed by software like
- XFree86 to initialize some video cards via BIOS. Disabling this
- option saves about 6k.
-
-config TOSHIBA
- tristate "Toshiba Laptop support"
- depends on X86_32
- ---help---
- This adds a driver to safely access the System Management Mode of
- the CPU on Toshiba portables with a genuine Toshiba BIOS. It does
- not work on models with a Phoenix BIOS. The System Management Mode
- is used to set the BIOS and power saving options on Toshiba portables.
-
- For information on utilities to make use of this driver see the
- Toshiba Linux utilities web site at:
- <http://www.buzzard.org.uk/toshiba/>.
-
- Say Y if you intend to run this kernel on a Toshiba portable.
- Say N otherwise.
-
-config I8K
- tristate "Dell laptop support"
- select HWMON
- ---help---
- This adds a driver to safely access the System Management Mode
- of the CPU on the Dell Inspiron 8000. The System Management Mode
- is used to read cpu temperature and cooling fan status and to
- control the fans on the I8K portables.
-
- This driver has been tested only on the Inspiron 8000 but it may
- also work with other Dell laptops. You can force loading on other
- models by passing the parameter `force=1' to the module. Use at
- your own risk.
-
- For information on utilities to make use of this driver see the
- I8K Linux utilities web site at:
- <http://people.debian.org/~dz/i8k/>
-
- Say Y if you intend to run this kernel on a Dell Inspiron 8000.
- Say N otherwise.
-
config X86_REBOOTFIXUPS
bool "Enable X86 board specific fixups for reboot"
depends on X86_32
@@ -1865,6 +1713,175 @@ config X86_NUMAQ
endif # X86_EXTENDED_PLATFORM
+menu "Obscure x86 Options"
+
+config X86_MPPARSE
+ bool "Enable MPS table" if ACPI || SFI
+ default y
+ depends on X86_LOCAL_APIC
+ ---help---
+ For old smp systems that do not have proper acpi support. Newer systems
+ (esp with 64bit cpus) with acpi support, MADT and DSDT will override it
+
+# Mark as expert because too many people got it wrong.
+# The code disables itself when not needed.
+config DMI
+ default y
+ bool "Enable DMI scanning" if EXPERT
+ ---help---
+ Enabled scanning of DMI to identify machine quirks. Say Y
+ here unless you have verified that your setup is not
+ affected by entries in the DMI blacklist. Required by PNP
+ BIOS code.
+
+config GART_IOMMU
+ bool "Old AMD GART IOMMU support"
+ select SWIOTLB
+ depends on X86_64 && PCI && AMD_NB
+ ---help---
+ Provides a driver for older AMD Athlon64/Opteron/Turion/Sempron
+ GART based hardware IOMMUs.
+
+ The GART supports full DMA access for devices with 32-bit access
+ limitations, on systems with more than 3 GB. This is usually needed
+ for USB, sound, many IDE/SATA chipsets and some other devices.
+
+ Newer systems typically have a modern AMD IOMMU, supported via
+ the CONFIG_AMD_IOMMU=y config option.
+
+ In normal configurations this driver is only active when needed:
+ there's more than 3 GB of memory and the system contains a
+ 32-bit limited device.
+
+ If unsure, say Y.
+
+config CALGARY_IOMMU
+ bool "IBM Calgary IOMMU support"
+ 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 X86_REROUTE_FOR_BROKEN_BOOT_IRQS
+ bool "Reroute for broken boot IRQs"
+ depends on X86_IO_APIC
+ ---help---
+ This option enables a workaround that fixes a source of
+ spurious interrupts. This is recommended when threaded
+ interrupt handling is used on systems where the generation of
+ superfluous "boot interrupts" cannot be disabled.
+
+ Some chipsets generate a legacy INTx "boot IRQ" when the IRQ
+ entry in the chipset's IO-APIC is masked (as, e.g. the RT
+ kernel does during interrupt handling). On chipsets where this
+ boot IRQ generation cannot be disabled, this workaround keeps
+ the original IRQ line masked so that only the equivalent "boot
+ IRQ" is delivered to the CPUs. The workaround also tells the
+ kernel to set up the IRQ handler on the boot IRQ line. In this
+ way only one interrupt is delivered to the kernel. Otherwise
+ the spurious second interrupt may cause the kernel to bring
+ down (vital) interrupt lines.
+
+ Only affects "broken" chipsets. Interrupt sharing may be
+ increased on these systems.
+
+config VM86
+ bool "Enable VM86 support" if EXPERT
+ default y
+ depends on X86_32
+ ---help---
+ This option is required by programs like DOSEMU to run 16-bit legacy
+ code on X86 processors. It also may be needed by software like
+ XFree86 to initialize some video cards via BIOS. Disabling this
+ option saves about 6k.
+
+config TOSHIBA
+ tristate "Toshiba Laptop support"
+ depends on X86_32
+ ---help---
+ This adds a driver to safely access the System Management Mode of
+ the CPU on Toshiba portables with a genuine Toshiba BIOS. It does
+ not work on models with a Phoenix BIOS. The System Management Mode
+ is used to set the BIOS and power saving options on Toshiba portables.
+
+ For information on utilities to make use of this driver see the
+ Toshiba Linux utilities web site at:
+ <http://www.buzzard.org.uk/toshiba/>.
+
+ Say Y if you intend to run this kernel on a Toshiba portable.
+ Say N otherwise.
+
+config I8K
+ tristate "Dell laptop support"
+ select HWMON
+ ---help---
+ This adds a driver to safely access the System Management Mode
+ of the CPU on the Dell Inspiron 8000. The System Management Mode
+ is used to read cpu temperature and cooling fan status and to
+ control the fans on the I8K portables.
+
+ This driver has been tested only on the Inspiron 8000 but it may
+ also work with other Dell laptops. You can force loading on other
+ models by passing the parameter `force=1' to the module. Use at
+ your own risk.
+
+ For information on utilities to make use of this driver see the
+ I8K Linux utilities web site at:
+ <http://people.debian.org/~dz/i8k/>
+
+ Say Y if you intend to run this kernel on a Dell Inspiron 8000.
+ Say N otherwise.
+
+config X86_32_IRIS
+ tristate "Eurobraille/Iris poweroff module"
+ depends on X86_32
+ ---help---
+ The Iris machines from EuroBraille do not have APM or ACPI support
+ to shut themselves down properly. A special I/O sequence is
+ needed to do so, which is what this module does at
+ kernel shutdown.
+
+ This is only for Iris machines from EuroBraille.
+
+ If unused, say N.
+
+config X86_PPRO_FENCE
+ bool "PentiumPro memory ordering errata workaround"
+ depends on M686 || M586MMX || M586TSC || M586 || M486 || MGEODEGX1
+ ---help---
+ Old PentiumPro multiprocessor systems had errata that could cause
+ memory operations to violate the x86 ordering standard in rare cases.
+ Enabling this option will attempt to work around some (but not all)
+ occurrences of this problem, at the cost of much heavier spinlock and
+ memory barrier operations.
+
+ If unsure, say n here. Even distro kernels should think twice before
+ enabling this: there are few systems, and an unlikely bug.
+
+endmenu # "Obscure x86 Options"
+
endmenu
config ARCH_ENABLE_MEMORY_HOTPLUG
diff -puN arch/x86/Kconfig.cpu~x86-mps-hide arch/x86/Kconfig.cpu
--- linux.git/arch/x86/Kconfig.cpu~x86-mps-hide 2014-01-13 11:11:35.977226919 -0800
+++ linux.git-davehans/arch/x86/Kconfig.cpu 2014-01-13 11:11:35.980227055 -0800
@@ -304,19 +304,6 @@ config X86_L1_CACHE_SHIFT
default "4" if MELAN || M486 || MGEODEGX1
default "5" if MWINCHIP3D || MWINCHIPC6 || MCRUSOE || MEFFICEON || MCYRIXIII || MK6 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || M586 || MVIAC3_2 || MGEODE_LX
-config X86_PPRO_FENCE
- bool "PentiumPro memory ordering errata workaround"
- depends on M686 || M586MMX || M586TSC || M586 || M486 || MGEODEGX1
- ---help---
- Old PentiumPro multiprocessor systems had errata that could cause
- memory operations to violate the x86 ordering standard in rare cases.
- Enabling this option will attempt to work around some (but not all)
- occurrences of this problem, at the cost of much heavier spinlock and
- memory barrier operations.
-
- If unsure, say n here. Even distro kernels should think twice before
- enabling this: there are few systems, and an unlikely bug.
-
config X86_F00F_BUG
def_bool y
depends on M586MMX || M586TSC || M586 || M486
_
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 09/12] x86 Kconfig: create mtrr menu under processsor options
2014-01-13 19:22 [PATCH 00/12] [v2] Reorganize x86 Kconfig menu Dave Hansen
` (7 preceding siblings ...)
2014-01-13 19:22 ` [PATCH 08/12] x86 Kconfig: bury obscure options Dave Hansen
@ 2014-01-13 19:22 ` Dave Hansen
2014-01-13 19:22 ` [PATCH 10/12] x86 Kconfig: MCE menu Dave Hansen
` (3 subsequent siblings)
12 siblings, 0 replies; 19+ messages in thread
From: Dave Hansen @ 2014-01-13 19:22 UTC (permalink / raw)
To: linux-kernel; +Cc: x86, Dave Hansen
From: Dave Hansen <dave.hansen@linux.intel.com>
This groups the MTRR and PAT options under their own menu and
puts them under the "Processor Options..." submenu. Note that I
slightly changed the MTRR prompt text since PAT is hidden under
here. This makes PAT easier to find since it "depends on MTRR"
anyway.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
---
linux.git-davehans/arch/x86/Kconfig | 161 +++++++++++++++++-------------------
1 file changed, 80 insertions(+), 81 deletions(-)
diff -puN arch/x86/Kconfig~x86-mtrr-menu arch/x86/Kconfig
--- linux.git/arch/x86/Kconfig~x86-mtrr-menu 2014-01-13 11:11:36.201237047 -0800
+++ linux.git-davehans/arch/x86/Kconfig 2014-01-13 11:11:36.204237182 -0800
@@ -481,6 +481,86 @@ config X86_CPUID
with major 203 and minors 0 to 31 for /dev/cpu/0/cpuid to
/dev/cpu/31/cpuid.
+menuconfig MTRR
+ def_bool y
+ prompt "MTRR (Memory Type Range Register) and PAT support" if EXPERT
+ ---help---
+ On Intel P6 family processors (Pentium Pro, Pentium II and later)
+ the Memory Type Range Registers (MTRRs) may be used to control
+ processor access to memory ranges. This is most useful if you have
+ a video (VGA) card on a PCI or AGP bus. Enabling write-combining
+ allows bus write transfers to be combined into a larger transfer
+ before bursting over the PCI/AGP bus. This can increase performance
+ of image write operations 2.5 times or more. Saying Y here creates a
+ /proc/mtrr file which may be used to manipulate your processor's
+ MTRRs. Typically the X server should use this.
+
+ This code has a reasonably generic interface so that similar
+ control registers on other processors can be easily supported
+ as well:
+
+ The Cyrix 6x86, 6x86MX and M II processors have Address Range
+ Registers (ARRs) which provide a similar functionality to MTRRs. For
+ these, the ARRs are used to emulate the MTRRs.
+ The AMD K6-2 (stepping 8 and above) and K6-3 processors have two
+ MTRRs. The Centaur C6 (WinChip) has 8 MCRs, allowing
+ write-combining. All of these processors are supported by this code
+ and it makes sense to say Y here if you have one of them.
+
+ Saying Y here also fixes a problem with buggy SMP BIOSes which only
+ set the MTRRs for the boot CPU and not for the secondary CPUs. This
+ can lead to all sorts of problems, so it's good to say Y here.
+
+ You can safely say Y even if your machine doesn't have MTRRs, you'll
+ just add about 9 KB to your kernel.
+
+ See <file:Documentation/x86/mtrr.txt> for more information.
+
+config MTRR_SANITIZER
+ def_bool y
+ prompt "MTRR cleanup support"
+ depends on MTRR
+ ---help---
+ Convert MTRR layout from continuous to discrete, so X drivers can
+ add writeback entries.
+
+ Can be disabled with disable_mtrr_cleanup on the kernel command line.
+ The largest mtrr entry size for a continuous block can be set with
+ mtrr_chunk_size.
+
+ If unsure, say Y.
+
+config MTRR_SANITIZER_ENABLE_DEFAULT
+ int "MTRR cleanup enable value (0-1)"
+ range 0 1
+ default "0"
+ depends on MTRR_SANITIZER
+ ---help---
+ Enable mtrr cleanup default value
+
+config MTRR_SANITIZER_SPARE_REG_NR_DEFAULT
+ int "MTRR cleanup spare reg num (0-7)"
+ range 0 7
+ default "1"
+ depends on MTRR_SANITIZER
+ ---help---
+ mtrr cleanup spare entries default, it can be changed via
+ mtrr_spare_reg_nr=N on the kernel command line.
+
+config X86_PAT
+ def_bool y
+ prompt "x86 PAT support" if EXPERT
+ depends on MTRR
+ ---help---
+ Use PAT attributes to setup page level cache control.
+
+ PATs are the modern equivalents of MTRRs and are much more
+ flexible than MTRRs.
+
+ Say N here if you see bootup problems (boot crash, boot hang,
+ spontaneous reboots) or a non-working video driver.
+
+ If unsure, say Y.
endmenu # Processor Options
@@ -1246,87 +1326,6 @@ config MATH_EMULATION
If you are not sure, say Y; apart from resulting in a 66 KB bigger
kernel, it won't hurt.
-config MTRR
- def_bool y
- prompt "MTRR (Memory Type Range Register) support" if EXPERT
- ---help---
- On Intel P6 family processors (Pentium Pro, Pentium II and later)
- the Memory Type Range Registers (MTRRs) may be used to control
- processor access to memory ranges. This is most useful if you have
- a video (VGA) card on a PCI or AGP bus. Enabling write-combining
- allows bus write transfers to be combined into a larger transfer
- before bursting over the PCI/AGP bus. This can increase performance
- of image write operations 2.5 times or more. Saying Y here creates a
- /proc/mtrr file which may be used to manipulate your processor's
- MTRRs. Typically the X server should use this.
-
- This code has a reasonably generic interface so that similar
- control registers on other processors can be easily supported
- as well:
-
- The Cyrix 6x86, 6x86MX and M II processors have Address Range
- Registers (ARRs) which provide a similar functionality to MTRRs. For
- these, the ARRs are used to emulate the MTRRs.
- The AMD K6-2 (stepping 8 and above) and K6-3 processors have two
- MTRRs. The Centaur C6 (WinChip) has 8 MCRs, allowing
- write-combining. All of these processors are supported by this code
- and it makes sense to say Y here if you have one of them.
-
- Saying Y here also fixes a problem with buggy SMP BIOSes which only
- set the MTRRs for the boot CPU and not for the secondary CPUs. This
- can lead to all sorts of problems, so it's good to say Y here.
-
- You can safely say Y even if your machine doesn't have MTRRs, you'll
- just add about 9 KB to your kernel.
-
- See <file:Documentation/x86/mtrr.txt> for more information.
-
-config MTRR_SANITIZER
- def_bool y
- prompt "MTRR cleanup support"
- depends on MTRR
- ---help---
- Convert MTRR layout from continuous to discrete, so X drivers can
- add writeback entries.
-
- Can be disabled with disable_mtrr_cleanup on the kernel command line.
- The largest mtrr entry size for a continuous block can be set with
- mtrr_chunk_size.
-
- If unsure, say Y.
-
-config MTRR_SANITIZER_ENABLE_DEFAULT
- int "MTRR cleanup enable value (0-1)"
- range 0 1
- default "0"
- depends on MTRR_SANITIZER
- ---help---
- Enable mtrr cleanup default value
-
-config MTRR_SANITIZER_SPARE_REG_NR_DEFAULT
- int "MTRR cleanup spare reg num (0-7)"
- range 0 7
- default "1"
- depends on MTRR_SANITIZER
- ---help---
- mtrr cleanup spare entries default, it can be changed via
- mtrr_spare_reg_nr=N on the kernel command line.
-
-config X86_PAT
- def_bool y
- prompt "x86 PAT support" if EXPERT
- depends on MTRR
- ---help---
- Use PAT attributes to setup page level cache control.
-
- PATs are the modern equivalents of MTRRs and are much more
- flexible than MTRRs.
-
- Say N here if you see bootup problems (boot crash, boot hang,
- spontaneous reboots) or a non-working video driver.
-
- If unsure, say Y.
-
config ARCH_USES_PG_UNCACHED
def_bool y
depends on X86_PAT
_
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 10/12] x86 Kconfig: MCE menu
2014-01-13 19:22 [PATCH 00/12] [v2] Reorganize x86 Kconfig menu Dave Hansen
` (8 preceding siblings ...)
2014-01-13 19:22 ` [PATCH 09/12] x86 Kconfig: create mtrr menu under processsor options Dave Hansen
@ 2014-01-13 19:22 ` Dave Hansen
2014-01-13 19:22 ` [PATCH 11/12] x86 Kconfig: create x86/Kconfig.virt Dave Hansen
` (2 subsequent siblings)
12 siblings, 0 replies; 19+ messages in thread
From: Dave Hansen @ 2014-01-13 19:22 UTC (permalink / raw)
To: linux-kernel; +Cc: x86, Dave Hansen
From: Dave Hansen <dave.hansen@linux.intel.com>
This is a fairly small one, but it still saves 3 lines in the
top-level menu.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
---
linux.git-davehans/arch/x86/Kconfig | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff -puN arch/x86/Kconfig~x86-mce-menu arch/x86/Kconfig
--- linux.git/arch/x86/Kconfig~x86-mce-menu 2014-01-13 11:11:36.408246405 -0800
+++ linux.git-davehans/arch/x86/Kconfig 2014-01-13 11:11:36.412246586 -0800
@@ -1234,7 +1234,7 @@ config X86_VISWS_APIC
def_bool y
depends on X86_32 && X86_VISWS
-config X86_MCE
+menuconfig X86_MCE
bool "Machine Check / overheating reporting"
default y
---help---
@@ -1267,10 +1267,6 @@ config X86_ANCIENT_MCE
systems. These typically need to be enabled explicitely on the command
line.
-config X86_MCE_THRESHOLD
- depends on X86_MCE_AMD || X86_MCE_INTEL
- def_bool y
-
config X86_MCE_INJECT
depends on X86_MCE
tristate "Machine check injector support"
@@ -1279,6 +1275,10 @@ config X86_MCE_INJECT
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_THRESHOLD
+ depends on X86_MCE_AMD || X86_MCE_INTEL
+ def_bool y
+
config X86_THERMAL_VECTOR
def_bool y
depends on X86_MCE_INTEL
_
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 11/12] x86 Kconfig: create x86/Kconfig.virt
2014-01-13 19:22 [PATCH 00/12] [v2] Reorganize x86 Kconfig menu Dave Hansen
` (9 preceding siblings ...)
2014-01-13 19:22 ` [PATCH 10/12] x86 Kconfig: MCE menu Dave Hansen
@ 2014-01-13 19:22 ` Dave Hansen
2014-01-13 22:46 ` Paolo Bonzini
2014-01-13 19:23 ` [PATCH 12/12] x86 Kconfig: move paravirt under "Virtualization" Dave Hansen
2014-01-14 14:25 ` [PATCH 00/12] [v2] Reorganize x86 Kconfig menu Borislav Petkov
12 siblings, 1 reply; 19+ messages in thread
From: Dave Hansen @ 2014-01-13 19:22 UTC (permalink / raw)
To: linux-kernel
Cc: x86, Dave Hansen, bp, dtor, kys, haiyangz, agraf, gleb, pbonzini
From: Dave Hansen <dave.hansen@linux.intel.com>
Right now, there is a "Enable paravirtualization code" option in
the "Processor Features" menu, which means Xen. There is also a
group of paravirtualization options specific to KVM under the
top-level "Virtualization" menu.
This creates a new hypervisor-independent arch/x86/Kconfig.virt
file, and moves the "Virtualization" menu to be defined in there.
This also removes the very counterintuitive references to
lguest/vhost code *from* kvm-specific code.
This also removes the silly:
depends on HAVE_KVM || X86
dependency. It makes zero sense to have entries defined in
arch/x86 depend on x86.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Dmitry Torokhov <dtor@vmware.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Alexander Graf <agraf@suse.de>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
---
linux.git-davehans/arch/x86/Kconfig | 2 +-
linux.git-davehans/arch/x86/Kconfig.virt | 18 ++++++++++++++++++
linux.git-davehans/arch/x86/kvm/Kconfig | 19 -------------------
3 files changed, 19 insertions(+), 20 deletions(-)
diff -puN arch/x86/Kconfig~x86-Kconfig-move-paravirt-under-virtualization arch/x86/Kconfig
--- linux.git/arch/x86/Kconfig~x86-Kconfig-move-paravirt-under-virtualization 2014-01-13 11:11:36.617255854 -0800
+++ linux.git-davehans/arch/x86/Kconfig 2014-01-13 11:11:36.620255990 -0800
@@ -2416,6 +2416,6 @@ source "security/Kconfig"
source "crypto/Kconfig"
-source "arch/x86/kvm/Kconfig"
+source "arch/x86/Kconfig.virt"
source "lib/Kconfig"
diff -puN /dev/null arch/x86/Kconfig.virt
--- /dev/null 2013-11-27 17:20:18.337162396 -0800
+++ linux.git-davehans/arch/x86/Kconfig.virt 2014-01-13 11:11:36.621256035 -0800
@@ -0,0 +1,18 @@
+
+menuconfig VIRTUALIZATION
+ bool "Virtualization"
+ default y
+ ---help---
+ Say Y here to get to see options for using your Linux host to run other
+ operating systems inside virtual machines (guests).
+ This option alone does not add any kernel code.
+
+ If you say N, all options in this submenu will be skipped and disabled.
+
+if VIRTUALIZATION
+
+source arch/x86/kvm/Kconfig
+source drivers/vhost/Kconfig
+source drivers/lguest/Kconfig
+
+endif # VIRTUALIZATION
diff -puN arch/x86/kvm/Kconfig~x86-Kconfig-move-paravirt-under-virtualization arch/x86/kvm/Kconfig
--- linux.git/arch/x86/kvm/Kconfig~x86-Kconfig-move-paravirt-under-virtualization 2014-01-13 11:11:36.618255899 -0800
+++ linux.git-davehans/arch/x86/kvm/Kconfig 2014-01-13 11:11:36.621256035 -0800
@@ -4,19 +4,6 @@
source "virt/kvm/Kconfig"
-menuconfig VIRTUALIZATION
- bool "Virtualization"
- depends on HAVE_KVM || X86
- default y
- ---help---
- Say Y here to get to see options for using your Linux host to run other
- operating systems inside virtual machines (guests).
- This option alone does not add any kernel code.
-
- If you say N, all options in this submenu will be skipped and disabled.
-
-if VIRTUALIZATION
-
config KVM
tristate "Kernel-based Virtual Machine (KVM) support"
depends on HAVE_KVM
@@ -93,9 +80,3 @@ config KVM_DEVICE_ASSIGNMENT
If unsure, say Y.
-# OK, it's a little counter-intuitive to do this, but it puts it neatly under
-# the virtualization menu.
-source drivers/vhost/Kconfig
-source drivers/lguest/Kconfig
-
-endif # VIRTUALIZATION
_
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH 11/12] x86 Kconfig: create x86/Kconfig.virt
2014-01-13 19:22 ` [PATCH 11/12] x86 Kconfig: create x86/Kconfig.virt Dave Hansen
@ 2014-01-13 22:46 ` Paolo Bonzini
2014-01-13 23:00 ` Dave Hansen
0 siblings, 1 reply; 19+ messages in thread
From: Paolo Bonzini @ 2014-01-13 22:46 UTC (permalink / raw)
To: Dave Hansen; +Cc: linux-kernel, x86, bp, dtor, kys, haiyangz, agraf, gleb
Il 13/01/2014 20:22, Dave Hansen ha scritto:
> From: Dave Hansen <dave.hansen@linux.intel.com>
>
> Right now, there is a "Enable paravirtualization code" option in
> the "Processor Features" menu, which means Xen. There is also a
> group of paravirtualization options specific to KVM under the
> top-level "Virtualization" menu.
>
> This creates a new hypervisor-independent arch/x86/Kconfig.virt
> file, and moves the "Virtualization" menu to be defined in there.
> This also removes the very counterintuitive references to
> lguest/vhost code *from* kvm-specific code.
>
> This also removes the silly:
>
> depends on HAVE_KVM || X86
>
> dependency. It makes zero sense to have entries defined in
> arch/x86 depend on x86.
>
> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Dmitry Torokhov <dtor@vmware.com>
> Cc: K. Y. Srinivasan <kys@microsoft.com>
> Cc: Haiyang Zhang <haiyangz@microsoft.com>
> Cc: Alexander Graf <agraf@suse.de>
> Cc: Gleb Natapov <gleb@redhat.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> ---
>
> linux.git-davehans/arch/x86/Kconfig | 2 +-
> linux.git-davehans/arch/x86/Kconfig.virt | 18 ++++++++++++++++++
> linux.git-davehans/arch/x86/kvm/Kconfig | 19 -------------------
> 3 files changed, 19 insertions(+), 20 deletions(-)
>
> diff -puN arch/x86/Kconfig~x86-Kconfig-move-paravirt-under-virtualization arch/x86/Kconfig
> --- linux.git/arch/x86/Kconfig~x86-Kconfig-move-paravirt-under-virtualization 2014-01-13 11:11:36.617255854 -0800
> +++ linux.git-davehans/arch/x86/Kconfig 2014-01-13 11:11:36.620255990 -0800
These diff headers are unreadable...
> @@ -2416,6 +2416,6 @@ source "security/Kconfig"
>
> source "crypto/Kconfig"
>
> -source "arch/x86/kvm/Kconfig"
> +source "arch/x86/Kconfig.virt"
>
> source "lib/Kconfig"
> diff -puN /dev/null arch/x86/Kconfig.virt
> --- /dev/null 2013-11-27 17:20:18.337162396 -0800
> +++ linux.git-davehans/arch/x86/Kconfig.virt 2014-01-13 11:11:36.621256035 -0800
> @@ -0,0 +1,18 @@
> +
> +menuconfig VIRTUALIZATION
> + bool "Virtualization"
Please rename this to "Hypervisor support" or "Virtual guest support" to
avoid confusion with KVM. Note there is a reference to
CONFIG_VIRTUALIZATION in configs/kvm_guest.config.
> + default y
> + ---help---
> + Say Y here to get to see options for using your Linux host to run other
> + operating systems inside virtual machines (guests).
> + This option alone does not add any kernel code.
> +
> + If you say N, all options in this submenu will be skipped and disabled.
> +
> +if VIRTUALIZATION
> +
> +source arch/x86/kvm/Kconfig
> +source drivers/vhost/Kconfig
> +source drivers/lguest/Kconfig
> +
> +endif # VIRTUALIZATION
> diff -puN arch/x86/kvm/Kconfig~x86-Kconfig-move-paravirt-under-virtualization arch/x86/kvm/Kconfig
> --- linux.git/arch/x86/kvm/Kconfig~x86-Kconfig-move-paravirt-under-virtualization 2014-01-13 11:11:36.618255899 -0800
> +++ linux.git-davehans/arch/x86/kvm/Kconfig 2014-01-13 11:11:36.621256035 -0800
> @@ -4,19 +4,6 @@
>
> source "virt/kvm/Kconfig"
>
> -menuconfig VIRTUALIZATION
> - bool "Virtualization"
> - depends on HAVE_KVM || X86
> - default y
> - ---help---
> - Say Y here to get to see options for using your Linux host to run other
> - operating systems inside virtual machines (guests).
> - This option alone does not add any kernel code.
> -
> - If you say N, all options in this submenu will be skipped and disabled.
> -
> -if VIRTUALIZATION
> -
> config KVM
> tristate "Kernel-based Virtual Machine (KVM) support"
> depends on HAVE_KVM
Definitely a good idea to separate KVM from the virtualization submenu.
> @@ -93,9 +80,3 @@ config KVM_DEVICE_ASSIGNMENT
>
> If unsure, say Y.
>
> -# OK, it's a little counter-intuitive to do this, but it puts it neatly under
> -# the virtualization menu.
> -source drivers/vhost/Kconfig
> -source drivers/lguest/Kconfig
> -
> -endif # VIRTUALIZATION
> _
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 11/12] x86 Kconfig: create x86/Kconfig.virt
2014-01-13 22:46 ` Paolo Bonzini
@ 2014-01-13 23:00 ` Dave Hansen
2014-01-13 23:12 ` Paolo Bonzini
0 siblings, 1 reply; 19+ messages in thread
From: Dave Hansen @ 2014-01-13 23:00 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: linux-kernel, x86, bp, dtor, kys, haiyangz, agraf, gleb
On 01/13/2014 02:46 PM, Paolo Bonzini wrote:
> Il 13/01/2014 20:22, Dave Hansen ha scritto:
>> diff -puN arch/x86/Kconfig~x86-Kconfig-move-paravirt-under-virtualization arch/x86/Kconfig
>> --- linux.git/arch/x86/Kconfig~x86-Kconfig-move-paravirt-under-virtualization 2014-01-13 11:11:36.617255854 -0800
>> +++ linux.git-davehans/arch/x86/Kconfig 2014-01-13 11:11:36.620255990 -0800
>
> These diff headers are unreadable...
Man, and I thought I was pedantic about about those kinds of things. I
guess git has spoiled everyone. :)
>> @@ -2416,6 +2416,6 @@ source "security/Kconfig"
>>
>> source "crypto/Kconfig"
>>
>> -source "arch/x86/kvm/Kconfig"
>> +source "arch/x86/Kconfig.virt"
>>
>> source "lib/Kconfig"
>> diff -puN /dev/null arch/x86/Kconfig.virt
>> --- /dev/null 2013-11-27 17:20:18.337162396 -0800
>> +++ linux.git-davehans/arch/x86/Kconfig.virt 2014-01-13 11:11:36.621256035 -0800
>> @@ -0,0 +1,18 @@
>> +
>> +menuconfig VIRTUALIZATION
>> + bool "Virtualization"
>
> Please rename this to "Hypervisor support" or "Virtual guest support" to
> avoid confusion with KVM. Note there is a reference to
> CONFIG_VIRTUALIZATION in configs/kvm_guest.config.
I'm not sure I'm following. When this gets done, we have a menu that says:
> --- Virtualization
> <*> Kernel-based Virtual Machine (KVM) support
> <*> KVM for Intel processors support
> <*> KVM for AMD processors support
> [*] Audit KVM MMU
> [*] KVM legacy PCI device assignment support
> < > Host kernel accelerator for virtio net
> [*] Linux guest support --->
So this new menu grouping includes both KVM, Xen, and lguest. It
includes both the host-side and guest-side support. Are you suggesting
that we separate out host and guest somehow?
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 11/12] x86 Kconfig: create x86/Kconfig.virt
2014-01-13 23:00 ` Dave Hansen
@ 2014-01-13 23:12 ` Paolo Bonzini
2014-01-14 0:04 ` Dave Hansen
0 siblings, 1 reply; 19+ messages in thread
From: Paolo Bonzini @ 2014-01-13 23:12 UTC (permalink / raw)
To: Dave Hansen; +Cc: linux-kernel, x86, bp, dtor, kys, haiyangz, agraf, gleb
Il 14/01/2014 00:00, Dave Hansen ha scritto:
>> > Please rename this to "Hypervisor support" or "Virtual guest support" to
>> > avoid confusion with KVM. Note there is a reference to
>> > CONFIG_VIRTUALIZATION in configs/kvm_guest.config.
> I'm not sure I'm following. When this gets done, we have a menu that says:
>
>> > --- Virtualization
>> > <*> Kernel-based Virtual Machine (KVM) support
>> > <*> KVM for Intel processors support
>> > <*> KVM for AMD processors support
>> > [*] Audit KVM MMU
>> > [*] KVM legacy PCI device assignment support
>> > < > Host kernel accelerator for virtio net
>> > [*] Linux guest support --->
Ok, got it now. The diff headers confused me...
I think this is as confusing as before, perhaps worse because it is not
clear that Linux guest support is not limited to KVM. If you really
want a Virtualization menu, you have to clearly separate the guest and host:
--- Virtualization
Linux guest support --->
Virtualization host support --->
with KVM and vhost under the second item.
> So this new menu grouping includes both KVM, Xen, and lguest. It
> includes both the host-side and guest-side support. Are you suggesting
> that we separate out host and guest somehow?
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH 11/12] x86 Kconfig: create x86/Kconfig.virt
2014-01-13 23:12 ` Paolo Bonzini
@ 2014-01-14 0:04 ` Dave Hansen
0 siblings, 0 replies; 19+ messages in thread
From: Dave Hansen @ 2014-01-14 0:04 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: linux-kernel, x86, bp, dtor, kys, haiyangz, agraf, gleb
On 01/13/2014 03:12 PM, Paolo Bonzini wrote:
> Il 14/01/2014 00:00, Dave Hansen ha scritto:
>>>> --- Virtualization
>>>> <*> Kernel-based Virtual Machine (KVM) support
>>>> <*> KVM for Intel processors support
>>>> <*> KVM for AMD processors support
>>>> [*] Audit KVM MMU
>>>> [*] KVM legacy PCI device assignment support
>>>> < > Host kernel accelerator for virtio net
>>>> [*] Linux guest support --->
>
> I think this is as confusing as before, perhaps worse because it is not
> clear that Linux guest support is not limited to KVM.
The "Linux guest support" menu is preexisting. This patch just moves it
verbatim from "Processor type and features" to "Virtualization". My
logic is that "Linux guest support" has a heck of a lot more to do with
"Virtualization" than the processor.
> If you really
> want a Virtualization menu, you have to clearly separate the guest and host:
>
> --- Virtualization
> Linux guest support --->
> Virtualization host support --->
>
> with KVM and vhost under the second item.
I think it's kinda silly to have folks chase through two levels of menus
when the submenus would have both fit on the screen anyway. Let's save
the layers of nesting for when we have 150 items in a menu.
I'll have new patches out in a sec.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH 12/12] x86 Kconfig: move paravirt under "Virtualization"
2014-01-13 19:22 [PATCH 00/12] [v2] Reorganize x86 Kconfig menu Dave Hansen
` (10 preceding siblings ...)
2014-01-13 19:22 ` [PATCH 11/12] x86 Kconfig: create x86/Kconfig.virt Dave Hansen
@ 2014-01-13 19:23 ` Dave Hansen
2014-01-14 14:25 ` [PATCH 00/12] [v2] Reorganize x86 Kconfig menu Borislav Petkov
12 siblings, 0 replies; 19+ messages in thread
From: Dave Hansen @ 2014-01-13 19:23 UTC (permalink / raw)
To: linux-kernel
Cc: x86, Dave Hansen, bp, dtor, kys, haiyangz, agraf, gleb, pbonzini
These options fit in much better in the "Virtualization" than in
the processor features menu. Move them.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Dmitry Torokhov <dtor@vmware.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Alexander Graf <agraf@suse.de>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
---
linux.git-davehans/arch/x86/Kconfig | 83 -----------------------------
linux.git-davehans/arch/x86/Kconfig.virt | 83 +++++++++++++++++++++++++++++
linux.git-davehans/arch/x86/lguest/Kconfig | 1
3 files changed, 83 insertions(+), 84 deletions(-)
diff -puN arch/x86/Kconfig~x86-Kconfig-move-paravirt-under-virtualization-really arch/x86/Kconfig
--- linux.git/arch/x86/Kconfig~x86-Kconfig-move-paravirt-under-virtualization-really 2014-01-13 11:11:36.847266252 -0800
+++ linux.git-davehans/arch/x86/Kconfig 2014-01-13 11:11:36.851266433 -0800
@@ -1018,89 +1018,6 @@ config X86_ES7000
Support for Unisys ES7000 systems. Say 'Y' here if this kernel is
supposed to run on an IA32-based Unisys ES7000 system.
-menuconfig HYPERVISOR_GUEST
- bool "Linux guest support"
- ---help---
- Say Y here to enable options for running Linux under various hyper-
- visors. This option enables basic hypervisor detection and platform
- setup.
-
- If you say N, all options in this submenu will be skipped and
- disabled, and Linux guest support won't be built in.
-
-if HYPERVISOR_GUEST
-
-config PARAVIRT
- bool "Enable paravirtualization code"
- ---help---
- This changes the kernel so it can modify itself when it is run
- under a hypervisor, potentially improving performance significantly
- over full virtualization. However, when run without a hypervisor
- the kernel is theoretically slower and slightly larger.
-
-config PARAVIRT_DEBUG
- bool "paravirt-ops debugging"
- depends on PARAVIRT && DEBUG_KERNEL
- ---help---
- Enable to debug paravirt_ops internals. Specifically, BUG if
- a paravirt_op is missing when it is called.
-
-config PARAVIRT_SPINLOCKS
- bool "Paravirtualization layer for spinlocks"
- depends on PARAVIRT && SMP
- select UNINLINE_SPIN_UNLOCK
- ---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).
-
- It has a minimal impact on native kernels and gives a nice performance
- benefit on paravirtualized KVM / Xen kernels.
-
- If you are unsure how to answer this question, answer Y.
-
-source "arch/x86/xen/Kconfig"
-
-config KVM_GUEST
- bool "KVM Guest support (including kvmclock)"
- depends on PARAVIRT
- select PARAVIRT_CLOCK
- default y
- ---help---
- This option enables various optimizations for running under the KVM
- hypervisor. It includes a paravirtualized clock, so that instead
- of relying on a PIT (or probably other) emulation by the
- underlying device model, the host provides the guest with
- timing infrastructure such as time of day, and system time
-
-config KVM_DEBUG_FS
- bool "Enable debug information for KVM Guests in debugfs"
- depends on KVM_GUEST && DEBUG_FS
- default n
- ---help---
- This option enables collection of various statistics for KVM guest.
- Statistics are displayed in debugfs filesystem. Enabling this option
- may incur significant overhead.
-
-source "arch/x86/lguest/Kconfig"
-
-config PARAVIRT_TIME_ACCOUNTING
- bool "Paravirtual steal time accounting"
- depends on PARAVIRT
- default n
- ---help---
- Select this option to enable fine granularity task steal time
- accounting. Time spent executing other tasks in parallel with
- the current vCPU is discounted from the vCPU power. To account for
- that, there can be a small performance impact.
-
- If in doubt, say N here.
-
-config PARAVIRT_CLOCK
- bool
-
-endif #HYPERVISOR_GUEST
-
config NO_BOOTMEM
def_bool y
diff -puN arch/x86/Kconfig.virt~x86-Kconfig-move-paravirt-under-virtualization-really arch/x86/Kconfig.virt
--- linux.git/arch/x86/Kconfig.virt~x86-Kconfig-move-paravirt-under-virtualization-really 2014-01-13 11:11:36.848266297 -0800
+++ linux.git-davehans/arch/x86/Kconfig.virt 2014-01-13 11:11:36.851266433 -0800
@@ -15,4 +15,87 @@ source arch/x86/kvm/Kconfig
source drivers/vhost/Kconfig
source drivers/lguest/Kconfig
+menuconfig HYPERVISOR_GUEST
+ bool "Linux guest support"
+ ---help---
+ Say Y here to enable options for running Linux under various hyper-
+ visors. This option enables basic hypervisor detection and platform
+ setup.
+
+ If you say N, all options in this submenu will be skipped and
+ disabled, and Linux guest support won't be built in.
+
+if HYPERVISOR_GUEST
+
+config PARAVIRT
+ bool "Enable paravirtualization code"
+ ---help---
+ This changes the kernel so it can modify itself when it is run
+ under a hypervisor, potentially improving performance significantly
+ over full virtualization. However, when run without a hypervisor
+ the kernel is theoretically slower and slightly larger.
+
+config PARAVIRT_DEBUG
+ bool "paravirt-ops debugging"
+ depends on PARAVIRT && DEBUG_KERNEL
+ ---help---
+ Enable to debug paravirt_ops internals. Specifically, BUG if
+ a paravirt_op is missing when it is called.
+
+config PARAVIRT_SPINLOCKS
+ bool "Paravirtualization layer for spinlocks"
+ depends on PARAVIRT && SMP
+ select UNINLINE_SPIN_UNLOCK
+ ---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).
+
+ It has a minimal impact on native kernels and gives a nice performance
+ benefit on paravirtualized KVM / Xen kernels.
+
+ If you are unsure how to answer this question, answer Y.
+
+source "arch/x86/xen/Kconfig"
+
+config KVM_GUEST
+ bool "KVM Guest support (including kvmclock)"
+ depends on PARAVIRT
+ select PARAVIRT_CLOCK
+ default y
+ ---help---
+ This option enables various optimizations for running under the KVM
+ hypervisor. It includes a paravirtualized clock, so that instead
+ of relying on a PIT (or probably other) emulation by the
+ underlying device model, the host provides the guest with
+ timing infrastructure such as time of day, and system time
+
+config KVM_DEBUG_FS
+ bool "Enable debug information for KVM Guests in debugfs"
+ depends on KVM_GUEST && DEBUG_FS
+ default n
+ ---help---
+ This option enables collection of various statistics for KVM guest.
+ Statistics are displayed in debugfs filesystem. Enabling this option
+ may incur significant overhead.
+
+source "arch/x86/lguest/Kconfig"
+
+config PARAVIRT_TIME_ACCOUNTING
+ bool "Paravirtual steal time accounting"
+ depends on PARAVIRT
+ default n
+ ---help---
+ Select this option to enable fine granularity task steal time
+ accounting. Time spent executing other tasks in parallel with
+ the current vCPU is discounted from the vCPU power. To account for
+ that, there can be a small performance impact.
+
+ If in doubt, say N here.
+
+config PARAVIRT_CLOCK
+ bool
+
+endif #HYPERVISOR_GUEST
+
endif # VIRTUALIZATION
diff -puN arch/x86/lguest/Kconfig~x86-Kconfig-move-paravirt-under-virtualization-really arch/x86/lguest/Kconfig
--- linux.git/arch/x86/lguest/Kconfig~x86-Kconfig-move-paravirt-under-virtualization-really 2014-01-13 11:11:36.849266343 -0800
+++ linux.git-davehans/arch/x86/lguest/Kconfig 2014-01-13 11:11:36.851266433 -0800
@@ -2,7 +2,6 @@ config LGUEST_GUEST
bool "Lguest guest support"
depends on X86_32 && PARAVIRT
select TTY
- select VIRTUALIZATION
select VIRTIO
select VIRTIO_CONSOLE
help
_
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH 00/12] [v2] Reorganize x86 Kconfig menu
2014-01-13 19:22 [PATCH 00/12] [v2] Reorganize x86 Kconfig menu Dave Hansen
` (11 preceding siblings ...)
2014-01-13 19:23 ` [PATCH 12/12] x86 Kconfig: move paravirt under "Virtualization" Dave Hansen
@ 2014-01-14 14:25 ` Borislav Petkov
2014-01-14 22:12 ` Dave Hansen
12 siblings, 1 reply; 19+ messages in thread
From: Borislav Petkov @ 2014-01-14 14:25 UTC (permalink / raw)
To: Dave Hansen; +Cc: linux-kernel, x86
On Mon, Jan 13, 2014 at 11:22:45AM -0800, Dave Hansen wrote:
>
> Changes from v1:
> * put MTRR under "Processor Options"
> * fix circular dependency introduced in the paravirt shuffle
> * dump extended platforms down to the end of the menu
>
> --
>
> The x86 "Processor type and features" menu has really been
> letting itself go over the years. It needs to be put on a
> diet as a new-year's resolution.
>
> This takes us from about 80 lines of options down to about 20.
Definitely a step in the right direction - thanks for doing that. A
couple of notes after staring at the new Kconfing menu:
* CONFIG_X86_X2APIC could go into "Processor Options and Features"
* We should put "Processor family (...) --->" into the main menu since
it is one of the most important ones.
* "Preemption Model" could be merged with "x86 Scheduler Options"
* Move CONFIG_SECCOMP, CONFIG_COMPAT_VDSO to obscure options?
* Move CONFIG_PHYSICAL_START to "Memory and NUMA Options"
* Maybe group CONFIG_RELOCATABLE, CONFIG_CC_STACKPROTECTOR,
CONFIG_PHYSICAL_ALIGN to a separate "Kernel image options" menu.
* CONFIG_CMDLINE_BOOL - I don't know about this one, it certainly
doesn't fit anywhere..
Anyway, just a couple of suggestions.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH 00/12] [v2] Reorganize x86 Kconfig menu
2014-01-14 14:25 ` [PATCH 00/12] [v2] Reorganize x86 Kconfig menu Borislav Petkov
@ 2014-01-14 22:12 ` Dave Hansen
0 siblings, 0 replies; 19+ messages in thread
From: Dave Hansen @ 2014-01-14 22:12 UTC (permalink / raw)
To: Borislav Petkov; +Cc: linux-kernel, x86
On 01/14/2014 06:25 AM, Borislav Petkov wrote:
> On Mon, Jan 13, 2014 at 11:22:45AM -0800, Dave Hansen wrote:
> * CONFIG_X86_X2APIC could go into "Processor Options and Features"
>
> * We should put "Processor family (...) --->" into the main menu since
> it is one of the most important ones.
>
> * "Preemption Model" could be merged with "x86 Scheduler Options"
>
> * Move CONFIG_SECCOMP, CONFIG_COMPAT_VDSO to obscure options?
I actually axed SECCOMP in another set of (arch-independent) patches.
> * Move CONFIG_PHYSICAL_START to "Memory and NUMA Options"
>
> * Maybe group CONFIG_RELOCATABLE, CONFIG_CC_STACKPROTECTOR,
> CONFIG_PHYSICAL_ALIGN to a separate "Kernel image options" menu.
This is used in concert with a few of the crash dump options, so I think
it makes sense to keep them grouped together.
> * CONFIG_CMDLINE_BOOL - I don't know about this one, it certainly
> doesn't fit anywhere..
>
> Anyway, just a couple of suggestions
Yup, thanks! Those are all good suggestions. I'll definitely take a
look at doing this in the next round. My focus at this point is to get
this set merged before I accrue too large of a pile.
^ permalink raw reply [flat|nested] 19+ messages in thread