We have some tests that assume we're using std=gnu99, which is fine on
most compilers, but some old compilers use a different default.

So make it explicit that we want to use std=gnu99.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

Perform an exec() class syscall with a suspended transaction.

This is a test for the bug we fixed in 8e96a87c5431 ("powerpc/tm: Always
reclaim in start_thread() for exec() class syscalls").

Signed-off-by: Cyril Bur <cyrilbur@gmail.com>
[mpe: Fix build errors, use a single binary for the test]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

PROT_SAO is a powerpc-specific flag to mmap(), and we rely on arch
specific logic to allow it to be passed to mmap().

Add a small test to ensure mmap() accepts PROT_SAO. We don't have a good
way to test that it actually causes the mapping to be created with the
right flags, so for now we just touch the mapping so it's faulted in. In
future we might be able to do something better.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

Use "Delta" to refer to the difference between measurements, rather than
"Error", so scripts that look for "Error" aren't confused into thinking
there was a failure.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

Test that an ISA 3.0 compliant machine performing an unaligned copy,
copy_first, paste or paste_last is sent a SIGBUS.

Signed-off-by: Chris Smart <chris@distroguy.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

These are useful little loops for smoke testing performance.

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

Currently it doesn't appear the resulting binary actually uses any
Altivec or VSX instructions the solution is to explicitly tell GCC to
use vector instructions and use vector types in the code.

Part of this this issue can be GCC version specific:

GCC 4.9.x is happy to use Altivec and VSX instructions if altivec.h is
includedi (and possibly if vector types are used), this also means that
4.9.x will use VSX instructions even if only -maltivec is passed. It is
also possible that Altivec instructions will be used even without
-maltivec or -mabi=altivec.

GCC 5.2.x complains about the lack of -maltivec parameter if altivec.h
is included and will not use VSX unless -mvsx is present on commandline.

GCC 5.3.0 has a regression that means __attribute__((__target__("no-vsx"))
fails to build. A fix is targeted for 5.4.

Furthermore LTO (Link Time Optimisation) doesn't play well with
__attribute__((__target__("no-vsx")), LTO can cause GCC to forget about
the attribute and compile with VSX instructions regardless. Be wary when
enabling -flfo for this test.

Signed-off-by: Cyril Bur <cyrilbur@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

When we inverted the behaviour of the flags we forgot to update the
usage message.

Fixes: 51c21e72eb99 ("selftests/powerpc: Make context_switch touch FP/altivec/vector by default")
Signed-off-by: Cyril Bur <cyrilbur@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

Excerpt from man 2 perf_event_open:

  /proc/sys/kernel/perf_event_paranoid
  The perf_event_paranoid file can be set to restrict access to the
  performance counters.
    2 allow only user-space measurements.
    1 allow both kernel and user measurements (default).
    0 allow access to CPU-specific data but not raw tracepoint samples.
   -1 no restrictions.

require_paranoia_below() should return 0 if perf_event_paranoid is below
a specified level, the value from perf_event_paranoid is read into an
unsigned long so the incorrect value is returned when
perf_event_paranoid is set to -1.

Without this patch applied there is the same number of selftests/powerpc
which skip when /proc/sys/kernel/perf_event_paranoid is set to 1 or -1
but no skips when set to zero.

With this patch applied there are no skipped selftests/powerpc test when
/proc/sys/kernel/perf_event_paranoid is set to 0 or -1.

Signed-off-by: Cyril Bur <cyrilbur@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

Adds two tests. One is a simple test to ensure that the new registers
LMRR and LMSER are properly maintained. The other actually uses the
existing EBB test infrastructure to test that LMRR and LMSER behave as
documented.

Signed-off-by: Jack Miller <jack@codezen.org>
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>