A new option is added to the relocs tool called '--realmode'.
This option causes the generation of 16-bit segment relocations
and 32-bit linear relocations for the real-mode code. When
the real-mode code is moved to the low-memory during kernel
initialization, these relocation entries can be used to
relocate the code properly.

In the assembly code 16-bit segment relocations must be relative
to the 'real_mode_seg' absolute symbol. Linear relocations must be
relative to a symbol prefixed with 'pa_'.

16-bit segment relocation is used to load cs:ip in 16-bit code.
Linear relocations are used in the 32-bit code for relocatable
data references. They are declared in the linker script of the
real-mode code.

The relocs tool is moved to arch/x86/tools/relocs.c, and added new
target archscripts that can be used to build scripts needed building
an architecture.  be compiled before building the arch/x86 tree.

[ hpa: accelerating this because it detects invalid absolute
  relocations, a serious bug in binutils 2.22.52.0.x which currently
  produces bad kernels. ]
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
Link: http://lkml.kernel.org/r/1336501366-28617-2-git-send-email-jarkko.sakkinen@intel.comSigned-off-by: NJarkko Sakkinen <jarkko.sakkinen@intel.com>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
Cc: <stable@vger.kernel.org>

On gccs that support AVX it's a good idea to disable that too, similar to
how SSE2, SSE1 etc. are already disabled. This prevents the compiler
from generating AVX ever implicitely.

No failure observed, just from review.

[ hpa: Marking this for urgent and stable, simply because the patch
  will either have absolutely no effect *or* it will avoid potentially
  very hard to debug failures. ]
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Link: http://lkml.kernel.org/r/1332960678-11879-1-git-send-email-andi@firstfloor.orgSigned-off-by: NH. Peter Anvin <hpa@zytor.com>
Cc: <stable@vger.kernel.org>

Fix:

 arch/x86/Makefile:96: *** recipe commences before first target.  Stop.

Cc: H. Peter Anvin <hpa@linux.intel.com>
Cc: H. J. Lu <hjl.tools@gmail.com>
Link: http://lkml.kernel.org/r/1329696488-16970-1-git-send-email-hpa@zytor.comSigned-off-by: NIngo Molnar <mingo@elte.hu>

If X32 is enabled in .config, but the binutils can't build it, issue a
warning and disable the feature rather than erroring out.

In order to support this, have CONFIG_X86_X32 be the option set in
Kconfig, and CONFIG_X86_X32_ABI be the option set by the Makefile when
it is enabled and binutils has been found to be functional.
Requested-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
Cc: H. J. Lu <hjl.tools@gmail.com>
Link: http://lkml.kernel.org/r/1329696488-16970-1-git-send-email-hpa@zytor.com

Generate system call tables and unistd_*.h automatically from the
tables in arch/x86/syscalls.  All other information, like NR_syscalls,
is auto-generated, some of which is in asm-offsets_*.c.

This allows us to keep all the system call information in one place,
and allows for kernel space and user space to see different
information; this is currently used for the ia32 system call numbers
when building the 64-bit kernel, but will be used by the x32 ABI in
the near future.

This also removes some gratuitious differences between i386, x86-64
and ia32; in particular, now all system call tables are generated with
the same mechanism.

Cc: H. J. Lu <hjl.tools@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Michal Marek <mmarek@suse.cz>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>

Kbuild allows for us to probe for the existence of specific constructs
in the assembler, use them to find out if we can use fxsave64 and
permit the compiler to generate better code.
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>

The arch/x86/Makefile uses scripts/gcc-x86_$(BITS)-has-stack-protector.sh
to check if cc1 supports -fstack-protector.  When -fPIE is passed to cc1,
these scripts fail causing stack protection to be disabled even when it
is available.

This fix is similar to commit c47efe55Reported-by: NKai Dietrich <mail@cleeus.de>
Signed-off-by: NMagnus Granberg <zorry@gentoo.org>
LKML-Reference: <20100913101319.748A1148E216@opensource.dyc.edu>
Signed-off-by: NAnthony G. Basile <basile@opensource.dyc.edu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>

The newer assemblers support the .cfi_sections directive so we can put
the CFI from .S files into the .debug_frame section that is preserved
in unstripped vmlinux and in separate debuginfo, rather than the
.eh_frame section that is now discarded by vmlinux.lds.S.
Signed-off-by: NRoland McGrath <roland@redhat.com>
LKML-Reference: <20100514044303.A6FE7400BE@magilla.sf.frob.com>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

For some reason the 64-bit tree was doing this differently and
I can't see why it would need to.

This correct behaviour when you have two GPUs plugged in and
32-bit put the console in one place and 64-bit in another.
Signed-off-by: NDave Airlie <airlied@redhat.com>
LKML-Reference: <1262847894-27498-1-git-send-email-airlied@gmail.com>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

STACKPROTECTOR_ALL has a really high overhead (runtime and stack
footprint) and is not really worth it protection wise (the
normal STACKPROTECTOR is in effect for all functions with
buffers already), so lets just remove the option entirely.
Reported-by: NDave Jones <davej@redhat.com>
Reported-by: NChuck Ebbert <cebbert@redhat.com>
Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
Cc: Eric Sandeen <sandeen@redhat.com>
LKML-Reference: <20091023073101.3dce4ebb@infradead.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Replace the use of CROSS_COMPILE to select a customized
installkernel script with the possibility to set INSTALLKERNEL
to select a custom installkernel script when running make:

    make INSTALLKERNEL=arm-installkernel install

With this patch we are now more consistent across
different architectures - they did not all support use
of CROSS_COMPILE.

The use of CROSS_COMPILE was a hack as this really belongs
to gcc/binutils and the installkernel script does not change
just because we change toolchain.

The use of CROSS_COMPILE caused troubles with an upcoming patch
that saves CROSS_COMPILE when a kernel is built - it would no
longer be installable.
[Thanks to Peter Z. for this hint]

This patch undos what Ian did in commit:

  0f8e2d62
  ("use ${CROSS_COMPILE}installkernel in arch/*/boot/install.sh")

The patch has been lightly tested on x86 only - but all changes
looks obvious.
Acked-by: NPeter Zijlstra <peterz@infradead.org>
Acked-by: Mike Frysinger <vapier@gentoo.org> [blackfin]
Acked-by: Russell King <linux@arm.linux.org.uk> [arm]
Acked-by: Paul Mundt <lethal@linux-sh.org> [sh]
Acked-by: "H. Peter Anvin" <hpa@zytor.com> [x86]
Cc: Ian Campbell <icampbell@arcom.com>
Cc: Tony Luck <tony.luck@intel.com> [ia64]
Cc: Fenghua Yu <fenghua.yu@intel.com> [ia64]
Cc: Hirokazu Takata <takata@linux-m32r.org> [m32r]
Cc: Geert Uytterhoeven <geert@linux-m68k.org> [m68k]
Cc: Kyle McMartin <kyle@mcmartin.ca> [parisc]
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> [powerpc]
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> [s390]
Cc: Thomas Gleixner <tglx@linutronix.de> [x86]
Cc: Ingo Molnar <mingo@redhat.com> [x86]
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Stack protector support was not detected when building with
ARCH=i386 on x86_64 systems:

  arch/x86/Makefile:80: stack protector enabled but no compiler support

The "-m32" argument needs to be passed to the detection script.
Signed-off-by: NMichal Schmidt <mschmidt@redhat.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Arjan van de Ven <arjan@infradead.org>
LKML-Reference: <20090829182718.10f566b1@leela>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
--

Add a user-space selftest of x86 instruction decoder at kernel build
time.
When CONFIG_X86_DECODER_SELFTEST=y, Kbuild builds a test harness of x86
instruction decoder and performs it after building vmlinux.
The test compares the results of objdump and x86 instruction decoder
code and check there are no differences.
Signed-off-by: NMasami Hiramatsu <mhiramat@redhat.com>
Signed-off-by: NJim Keniston <jkenisto@us.ibm.com>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Cc: Avi Kivity <avi@redhat.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Frank Ch. Eigler <fche@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Jason Baron <jbaron@redhat.com>
Cc: K.Prasad <prasad@linux.vnet.ibm.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Li Zefan <lizf@cn.fujitsu.com>
Cc: Przemysław Pawełczyk <przemyslaw@pawelczyk.it>
Cc: Roland McGrath <roland@redhat.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Tom Zanussi <tzanussi@gmail.com>
Cc: Vegard Nossum <vegard.nossum@gmail.com>
LKML-Reference: <20090813203421.31965.29006.stgit@localhost.localdomain>
Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>

Add another option when selecting CPU family so the kernel can be
optimized for Intel Atom CPUs. If GCC supports tuning options for
Intel Atom they will be used.
Signed-off-by: NTobias Doerffel <tobias.doerffel@gmail.com>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
LKML-Reference: <1251018457-19157-1-git-send-email-tobias.doerffel@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Signed-off-by: NFrans Pop <elendil@planet.nl>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Reviewed-by: NWANG Cong <xiyou.wangcong@gmail.com>
LKML-Reference: <200907232056.28635.elendil@planet.nl>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

General description: kmemcheck is a patch to the linux kernel that
detects use of uninitialized memory. It does this by trapping every
read and write to memory that was allocated dynamically (e.g. using
kmalloc()). If a memory address is read that has not previously been
written to, a message is printed to the kernel log.

Thanks to Andi Kleen for the set_memory_4k() solution.

Andrew Morton suggested documenting the shadow member of struct page.
Signed-off-by: NVegard Nossum <vegardno@ifi.uio.no>
Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>

[export kmemcheck_mark_initialized]
[build fix for setup_max_cpus]
Signed-off-by: NIngo Molnar <mingo@elte.hu>

[rebased for mainline inclusion]
Signed-off-by: NVegard Nossum <vegardno@ifi.uio.no>

It is common to use "make install" in restricted environments which
differ from the one which was actually used to build the kernel.  In
such environments it is highly undesirable to trigger a rebuild of any
part of the system.  Worse, the rebuild may be spurious, triggered by
differences in the environment.
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
LKML-Reference: <20090415234642.GA28531@uranus.ravnborg.org>

Introducing this Kbuild file allow us to:

    make arch/x86/

And thus building all the core part of x86.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Cc: Jaswinder Singh Rajput <jaswinder@kernel.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Impact: cleanup

Instead of using CLEAN_FILES in arch/x86/Makefile, add generated files
to targets in arch/x86/boot/Makefile, so they will get naturally
cleaned up by "make clean".

Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

Impact: cleanup

Remove targets that were used for zImage only, and Makefile
infrastructure that was there to support the zImage/bzImage split.
Reported-by: NPaul Bolle <pebolle@tiscali.nl>
LKML-Reference: <1236879901.24144.26.camel@test.thuisdomein>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

Impact: no default -fno-stack-protector if stackp is enabled, cleanup

Stackprotector make rules had the following problems.

* cc support test and warning are scattered across makefile and
  kernel/panic.c.

* -fno-stack-protector was always added regardless of configuration.

Update such that cc support test and warning are contained in makefile
and -fno-stack-protector is added iff stackp is turned off.  While at
it, prepare for 32bit support.
Signed-off-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Remove the 32-bit subarchitecture support code.

All subarchitectures but Voyager have been converted. Voyager will be
done later or will be removed.
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Remove remaining bits of the subarchitecture code. Now that all the
special platforms are runtime probed and runtime handled, we can remove
these facilities.
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

first step to add RDC321x support to the default PC architecture.
Signed-off-by: NIngo Molnar <mingo@elte.hu>

remove leftover arch/x86/mach-visws/* files.
Signed-off-by: NIngo Molnar <mingo@elte.hu>

this is the big move: flip over VISWS to generic arch support.

From this commit on CONFIG_X86_VISWS is just another (default-disabled)
option that turns on certain quirks - no other complications.
Signed-off-by: NIngo Molnar <mingo@elte.hu>

... so it could fall back to normal numa and we'd reduce the impact of the
NUMAQ subarch.

NUMAQ depends on GENERICARCH
also decouple genericarch numa from acpi.
also make it fall back to bigsmp if apicid > 8.
Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

This patch extracts the common part of head32.c and head64.c into head.c.
Signed-off-by: NHuang Ying <ying.huang@intel.com>
Cc: andi@firstfloor.org
Cc: mingo@redhat.com
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

If the user selects the stack-protector config option, but does not have
a gcc that has the right bits enabled (for example because it isn't build
with a glibc that supports TLS, as is common for cross-compilers, but also
because it may be too old), then the runtime test fails right now.

This patch adds a warning message for this scenario. This warning accomplishes
two goals
1) the user is informed that the security option he selective isn't available
2) the user is suggested to turn of the CONFIG option that won't work for him,
   and would make the runtime test fail anyway.
Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Use build target when creating compatibility link, and use $(boot)
where possible.
Signed-off-by: NJan Beulich <jbeulich@novell.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

this patch allows x86_64 to use subarch mach_ headers
in practice, since x86_64 does not have any subarch, it
will use mach_default. But it will allow for substantially
less code duplication
Signed-off-by: NGlauber Costa <gcosta@redhat.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Copy x86_64 and add a head32.c so we can start moving early
architecture initialization out of assembly.

[ Sam Ravnborg <sam@ravnborg.org>: updated it to x86 ]
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

I suggest to make the vdso_install step independent as
in following patch.

This solves the issue at ahnd and still gives us the posibility
to install the files should they be needed.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Move arch/x86/kernel/suspend_64.c to arch/x86/power .

Move arch/x86/kernel/suspend_asm_64.S to arch/x86/power
as hibernate_asm_64.S .

Update purpose and copyright information in
arch/x86/power/suspend_64.c and
arch/x86/power/hibernate_asm_64.S .

Update the Makefiles in arch/x86, arch/x86/kernel and
arch/x86/power to reflect the above changes.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Do this rather than defining a global version and overriding it in
almost all cases in order to make subsequent patches simpler.
Signed-off-by: NIan Campbell <ijc@hellion.org.uk>
Acked-by: NH. Peter Anvin <hpa@zytor.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Doing a make randconfig I came across this error in the Makefile.

This patch makes a directory out of arch/x86/mach-default for
CONFIG_X86_RDC321X
Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This paves the way for multiple architecture support.  Note that while
ioapic.c could potentially be shared with ia64, it is also moved.
Signed-off-by: NAvi Kivity <avi@qumranet.com>

This patch adds support for the RDC R-321x system-on-chip,
also known as R-861x-(G). It uses the generic GPIO API and
has support for the on-chip hardware watchdog.

Build-fix from: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NFlorian Fainelli <florian.fainelli@telecomint.eu>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Add missing targets and missing options in x86 make help

[ mingo@elte.hu: more whitespace cleanups ]
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>