linux-toradex.git/arch/x86/tools, branch v3.9.2

Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2013-02-04T20:57:09+00:00

Pull perf fixes from Ingo Molnar:
 "Three fixlets and two small (and low risk) hw-enablement changes"

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf: Fix event group context move
  x86/perf: Add IvyBridge EP support
  perf/x86: Fix P6 driver section warning
  arch/x86/tools/insn_sanity.c: Identify source of messages
  perf/x86: Enable Intel Lincroft/Penwell/Cloverview Atom support

x86/boot: Fix minor fd leakage in tools/relocs.c

2013-01-27T18:24:28+00:00

The opened file should be closed.

Signed-off-by: Cong Ding 
Cc: Kusanagi Kouichi 
Cc: Jarkko Sakkinen 
Cc: Jiri Kosina 
Cc: Matt Fleming 
Link: http://lkml.kernel.org/r/1358183628-27784-1-git-send-email-dinggnu@gmail.com
Signed-off-by: Ingo Molnar

arch/x86/tools/insn_sanity.c: Identify source of messages

2013-01-24T14:57:53+00:00

The kernel build prints:

  Building modules, stage 2.
  TEST    posttest
  MODPOST 3821 modules
  TEST    posttest
 Success: decoded and checked 1000000 random instructions with 0
 errors (seed:0xaac4bc47)   CC      arch/x86/boot/a20.o
  CC      arch/x86/boot/cmdline.o
  AS      arch/x86/boot/copy.o
  HOSTCC  arch/x86/boot/mkcpustr
  CC      arch/x86/boot/cpucheck.o
  CC      arch/x86/boot/early_serial_console.o

which is irritating because you don't know what program is
proudly pronouncing its success.

So, as described in "console mode programming user interface
guidelines version 101" which doesn't exist, change this program
to identify the source of its messages.

Signed-off-by: Andrew Morton 
Cc: "H. Peter Anvin" 
Cc: Masami Hiramatsu 
Signed-off-by: Ingo Molnar

x86: Fix the error of using "const" in gen-insn-attr-x86.awk

2012-12-10T18:31:24+00:00

The original version code causes following sparse warnings:
arch/x86/lib/inat-tables.c:1080:25: warning: duplicate const
arch/x86/lib/inat-tables.c:1095:25: warning: duplicate const
arch/x86/lib/inat-tables.c:1118:25: warning: duplicate const

for the variables inat_escape_tables, inat_group_tables, and inat_avx_tables
in the code generated by gen-insn-attr-x86.awk.

The author Masami Hiramutsu says here is to make both the value pointed by the
pointers and the pointers itself read-only, so we move the "const" to be after
the "*".

Signed-off-by: Cong Ding 
Link: http://lkml.kernel.org/r/20121209082103.GA9181@gmail.com
Acked-by: Masami Hiramatsu 
Signed-off-by: H. Peter Anvin

UAPI: x86: Fix the test_get_len tool

2012-10-02T17:01:56+00:00

Fix the x86 test_get_len tool to have the right include paths in the right
order (it includes a non-exported kernel header directly), otherwise errors
like the following occur:

/data/fs/linux-2.6-hdr/include/linux/types.h:18:26: error: conflicting types for 'fd_set'
/usr/include/sys/select.h:78:5: note: previous declaration of 'fd_set' was here

and

/data/fs/linux-2.6-hdr/include/linux/string.h:42:12: error: expected identifier or '(' before '__extension__'

Signed-off-by: David Howells 
Acked-by: Arnd Bergmann 
Acked-by: Thomas Gleixner 
Acked-by: Paul E. McKenney 
Acked-by: Dave Jones

x86/decoder: Fix bsr/bsf/jmpe decoding with operand-size prefix

2012-06-06T06:54:18+00:00

Fix the x86 instruction decoder to decode bsr/bsf/jmpe with
operand-size prefix (66h). This fixes the test case failure
reported by Linus, attached below.

bsf/bsr/jmpe have a special encoding. Opcode map in
Intel Software Developers Manual vol2 says they have
TZCNT/LZCNT variants if it has F3h prefix. However, there
is no information if it has other 66h or F2h prefixes.
Current instruction decoder supposes that those are
bad instructions, but it actually accepts at least
operand-size prefixes.

H. Peter Anvin further explains:

 " TZCNT/LZCNT are F3 + BSF/BSR exactly because the F2 and
   F3 prefixes have historically been no-ops with most instructions.
   This allows software to unconditionally use the prefixed versions
   and get TZCNT/LZCNT on the processors that have them if they don't
   care about the difference. "

This fixes errors reported by test_get_len:

  Warning: arch/x86/tools/test_get_len found difference at :ffffffff81036d87
  Warning: ffffffff81036de5:	66 0f bc c2          	bsf    %dx,%ax
  Warning: objdump says 4 bytes, but insn_get_length() says 3
  Warning: arch/x86/tools/test_get_len found difference at :ffffffff81036ea6
  Warning: ffffffff81036f04:	66 0f bd c2          	bsr    %dx,%ax
  Warning: objdump says 4 bytes, but insn_get_length() says 3
  Warning: decoded and checked 13298882 instructions with 2 warnings

Reported-by: Linus Torvalds 
Reported-by: Pekka Enberg 
Signed-off-by: Masami Hiramatsu 
Cc: "H. Peter Anvin" 
Cc: 
Link: http://lkml.kernel.org/r/20120604150911.22338.43296.stgit@localhost.localdomain
Signed-off-by: Ingo Molnar

Merge branch 'x86-trampoline-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2012-05-30T03:14:53+00:00

Pull x86 trampoline rework from H. Peter Anvin:
 "This code reworks all the "trampoline"/"realmode" code (various bits
  that need to live in the first megabyte of memory, most but not all of
  which runs in real mode at some point) in the kernel into a single
  object.  The main reason for doing this is that it eliminates the last
  place in the kernel where we needed pages to be mapped RWX.  This code
  separates all that code into proper R/RW/RX pages."

Fix up conflicts in arch/x86/kernel/Makefile (mca removed next to reboot
code), and arch/x86/kernel/reboot.c (reboot code moved around in one
branch, modified in this one), and arch/x86/tools/relocs.c (mostly same
code came in earlier due to working around the ld bugs just before the
3.4 release).

Also remove stale x86-relocs entry from scripts/.gitignore as per Peter
Anvin.

* commit '61f5446169046c217a5479517edac3a890c3bee7': (36 commits)
  x86, realmode: Move end signature into header.S
  x86, relocs: When printing an error, say relative or absolute
  x86, relocs: More relocations which may end up as absolute
  x86, relocs: Workaround for binutils 2.22.52.0.1 section bug
  xen-acpi-processor: Add missing #include 
  acpi, bgrd: Add missing  to drivers/acpi/bgrt.c
  x86, realmode: Change EFER to a single u64 field
  x86, realmode: Move kernel/realmode.c to realmode/init.c
  x86, realmode: Move not-common bits out of trampoline_common.S
  x86, realmode: Mask out EFER.LMA when saving trampoline EFER
  x86, realmode: Fix no cache bits test in reboot_32.S
  x86, realmode: Make sure all generated files are listed in targets
  x86, realmode: build fix: remove duplicate build
  x86, realmode: read cr4 and EFER from kernel for 64-bit trampoline
  x86, realmode: fixes compilation issue in tboot.c
  x86, realmode: move relocs from scripts/ to arch/x86/tools
  x86, realmode: header for trampoline code
  x86, realmode: flattened rm hierachy
  x86, realmode: don't copy real_mode_header
  x86, realmode: fix 64-bit wakeup sequence
  ...

x86, relocs: Add jiffies and jiffies_64 to the relative whitelist

2012-05-24T14:16:18+00:00

The symbol jiffies is created in the linker script as an alias to
jiffies_64.  Unfortunately this is done outside any section, and
apparently GNU ld 2.21 doesn't carry the section with it, so we end up
with an absolute symbol and therefore a broken kernel.

Add jiffies and jiffies_64 to the whitelist.

The most disturbing bit with this discovery is that it shows that we
have had multiple linker bugs in this area crossing multiple
generations, and have been silently building bad kernels for some time.

Link: http://lkml.kernel.org/r/20120524171604.0d98284f3affc643e9714470@canb.auug.org.au
Reported-by: Stephen Rothwell 
Signed-off-by: H. Peter Anvin 
Cc:  v3.4

x86-32, relocs: Whitelist more symbols for ld bug workaround

2012-05-23T21:02:34+00:00

As noted in checkin:

a3e854d95 x86, relocs: Workaround for binutils 2.22.52.0.1 section bug

ld version 2.22.52.0.[12] can incorrectly promote relative symbols to
absolute, if the output section they appear in is otherwise empty.

Since checkin:

6520fe55 x86, realmode: 16-bit real-mode code support for relocs tool

we actually check for this and error out rather than silently creating
a kernel which will malfunction if relocated.

Ingo found a configuration in which __start_builtin_fw triggered the
warning.

Go through the linker script sources and look for more symbols that
could plausibly get bogusly promoted to absolute, and add them to the
whitelist.

In general, if the following error triggers:

	Invalid absolute R_386_32 relocation: 

... then we should verify that  is really meant to be
relocated, and add it and any related symbols manually to the S_REL
regexp.

Please note that 6520fe55 does not introduce the error, only the check
for the error -- without 6520fe55 this version of ld will simply
produce a corrupt kernel if CONFIG_RELOCATABLE is set on x86-32.

Reported-by: Ingo Molnar 
Signed-off-by: H. Peter Anvin 
Cc:  v3.4

x86, relocs: When printing an error, say relative or absolute

2012-05-19T02:50:02+00:00

When the relocs tool throws an error, let the error message say if it
is an absolute or relative symbol.  This should make it a lot more
clear what action the programmer needs to take and should help us find
the reason if additional symbol bugs show up.

Signed-off-by: H. Peter Anvin 
Cc: