Pull sgi into release branch

[linux-2.6] / arch / i386 / Kconfig

diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig
index 1f0f7b60995e38a2edc0f05161b99613dff9a987..0dfee812811a9c75427551ef8177b45f2ca7a998 100644 (file)
--- a/arch/i386/Kconfig
+++ b/arch/i386/Kconfig
@@ -49,6 +49,11 @@ config GENERIC_IOMAP
        bool
        default y
 
+config GENERIC_BUG
+       bool
+       default y
+       depends on BUG
+
 config GENERIC_HWEIGHT
        bool
        default y
@@ -182,6 +187,18 @@ config X86_ES7000
 
 endchoice
 
+config PARAVIRT
+       bool "Paravirtualization support (EXPERIMENTAL)"
+       depends on EXPERIMENTAL
+       depends on !(X86_VISWS || X86_VOYAGER)
+       help
+         Paravirtualization is a way of running multiple instances of
+         Linux on the same machine, under a hypervisor.  This option
+         changes the kernel so it can modify itself when it is run
+         under a hypervisor, improving performance significantly.
+         However, when run without a hypervisor the kernel is
+         theoretically slower.  If in doubt, say N.
+
 config ACPI_SRAT
        bool
        default y
@@ -443,7 +460,8 @@ source "drivers/firmware/Kconfig"
 
 choice
        prompt "High Memory Support"
-       default NOHIGHMEM
+       default HIGHMEM4G if !X86_NUMAQ
+       default HIGHMEM64G if X86_NUMAQ
 
 config NOHIGHMEM
        bool "off"
@@ -710,20 +728,6 @@ config BOOT_IOREMAP
        depends on (((X86_SUMMIT || X86_GENERICARCH) && NUMA) || (X86 && EFI))
        default y
 
-config REGPARM
-       bool "Use register arguments"
-       default y
-       help
-       Compile the kernel with -mregparm=3. This instructs gcc to use
-       a more efficient function call ABI which passes the first three
-       arguments of a function call via registers, which results in denser
-       and faster code.
-
-       If this option is disabled, then the default ABI of passing
-       arguments via the stack is used.
-
-       If unsure, say Y.
-
 config SECCOMP
        bool "Enable seccomp to safely compute untrusted bytecode"
        depends on PROC_FS
@@ -773,6 +777,47 @@ config CRASH_DUMP
           PHYSICAL_START.
          For more details see Documentation/kdump/kdump.txt
 
+config PHYSICAL_START
+       hex "Physical address where the kernel is loaded" if (EMBEDDED || CRASH_DUMP)
+       default "0x100000"
+       help
+         This gives the physical address where the kernel is loaded.
+
+         If kernel is a not relocatable (CONFIG_RELOCATABLE=n) then
+         bzImage will decompress itself to above physical address and
+         run from there. Otherwise, bzImage will run from the address where
+         it has been loaded by the boot loader and will ignore above physical
+         address.
+
+         In normal kdump cases one does not have to set/change this option
+         as now bzImage can be compiled as a completely relocatable image
+         (CONFIG_RELOCATABLE=y) and be used to load and run from a different
+         address. This option is mainly useful for the folks who don't want
+         to use a bzImage for capturing the crash dump and want to use a
+         vmlinux instead. vmlinux is not relocatable hence a kernel needs
+         to be specifically compiled to run from a specific memory area
+         (normally a reserved region) and this option comes handy.
+
+         So if you are using bzImage for capturing the crash dump, leave
+         the value here unchanged to 0x100000 and set CONFIG_RELOCATABLE=y.
+         Otherwise if you plan to use vmlinux for capturing the crash dump
+         change this value to start of the reserved region (Typically 16MB
+         0x1000000). In other words, it can be set based on the "X" value as
+         specified in the "crashkernel=YM@XM" command line boot parameter
+         passed to the panic-ed kernel. Typically this parameter is set as
+         crashkernel=64M@16M. Please take a look at
+         Documentation/kdump/kdump.txt for more details about crash dumps.
+
+         Usage of bzImage for capturing the crash dump is recommended as
+         one does not have to build two kernels. Same kernel can be used
+         as production kernel and capture kernel. Above option should have
+         gone away after relocatable bzImage support is introduced. But it
+         is present because there are users out there who continue to use
+         vmlinux for dump capture. This option should go away down the
+         line.
+
+         Don't change this unless you know what you are doing.
+
 config RELOCATABLE
        bool "Build a relocatable kernel(EXPERIMENTAL)"
        depends on EXPERIMENTAL