~jpdonnelly/ubuntu/+source/linux/+git/xenial:master-next

Last commit made on 2017-01-13
Get this branch:
git clone -b master-next https://git.launchpad.net/~jpdonnelly/ubuntu/+source/linux/+git/xenial
Only John Donnelly can upload to this branch. If you are John Donnelly please log in for upload directions.

Branch merges

Branch information

Name:
master-next
Repository:
lp:~jpdonnelly/ubuntu/+source/linux/+git/xenial

Recent commits

4583c20... by John Donnelly

UBUNTU: Ubuntu-4.4.0-60.81

Signed-off-by: John Donnelly <email address hidden>

fe22fa3... by Thomas Huth <email address hidden>

KVM: PPC: Book3S PR: Fix illegal opcode emulation

BugLink: http://bugs.launchpad.net/bugs/1634129

If kvmppc_handle_exit_pr() calls kvmppc_emulate_instruction() to emulate
one instruction (in the BOOK3S_INTERRUPT_H_EMUL_ASSIST case), it calls
kvmppc_core_queue_program() afterwards if kvmppc_emulate_instruction()
returned EMULATE_FAIL, so the guest gets an program interrupt for the
illegal opcode.
However, the kvmppc_emulate_instruction() also tried to inject a
program exception for this already, so the program interrupt gets
injected twice and the return address in srr0 gets destroyed.
All other callers of kvmppc_emulate_instruction() are also injecting
a program interrupt, and since the callers have the right knowledge
about the srr1 flags that should be used, it is the function
kvmppc_emulate_instruction() that should _not_ inject program
interrupts, so remove the kvmppc_core_queue_program() here.

This fixes the issue discovered by Laurent Vivier with kvm-unit-tests
where the logs are filled with these messages when the test tries
to execute an illegal instruction:

     Couldn't emulate instruction 0x00000000 (op 0 xop 0)
     kvmppc_handle_exit_pr: emulation at 700 failed (00000000)

Signed-off-by: Thomas Huth <email address hidden>
Reviewed-by: Alexander Graf <email address hidden>
Tested-by: Laurent Vivier <email address hidden>
Signed-off-by: Paul Mackerras <email address hidden>
(cherry picked from commit 708e75a3ee750dce1072134e630d66c4e6eaf63c)
Signed-off-by: Tim Gardner <email address hidden>
Acked-by: Colin Ian King <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Luis Henriques <email address hidden>

528506b... by Sukadev Bhattiprolu <email address hidden>

powerpc/perf/24x7: Eliminate domain suffix in event names

BugLink: http://bugs.launchpad.net/bugs/1560482

The Physical Core events of the 24x7 PMU can be monitored across various
domains (physical core, vcpu home core, vcpu home node etc). For each of
these core events, we currently create multiple events in sysfs, one for
each domain the event can be monitored in. These events are distinguished
by their suffixes like __PHYS_CORE, __VCPU_HOME_CORE etc.

Rather than creating multiple such entries, we could let the user specify
make 'domain' index a required parameter and let the user specify a value
for it (like they currently specify the core index).

 $ cat /sys/bus/event_source/devices/hv_24x7/events/HPM_CCYC
 domain=?,offset=0x98,core=?,lpar=0x0

 $ perf stat -C 0 -e hv_24x7/HPM_CCYC,domain=2,core=1/ true

(the 'domain=?' and 'core=?' in sysfs tell perf tool to enforce them as
required parameters).

This simplifies the interface and allows users to identify events by the
name specified in the catalog (User can determine the domain index by
referring to '/sys/bus/event_source/devices/hv_24x7/interface/domains').

Eliminating the event suffix eliminates several functions and simplifies
code.

Note that Physical Chip events can only be monitored in the chip domain
so those events have the domain set to 1 (rather than =?) and users don't
need to specify the domain index for the Chip events.

 $ cat /sys/bus/event_source/devices/hv_24x7/events/PM_XLINK_CYCLES
 domain=1,offset=0x230,chip=?,lpar=0x0

 $ perf stat -C 0 -e hv_24x7/PM_XLINK_CYCLES,chip=1/ true

Signed-off-by: Sukadev Bhattiprolu <email address hidden>
Signed-off-by: Michael Ellerman <email address hidden>
(cherry picked from commit 8f69dc701aac170421117adf7e04d8ec7031a05f)
Signed-off-by: Tim Gardner <email address hidden>
Acked-by: Seth Forshee <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Luis Henriques <email address hidden>

162729e... by Sukadev Bhattiprolu <email address hidden>

powerpc/perf/hv-24x7: Display domain indices in sysfs

BugLink: http://bugs.launchpad.net/bugs/1560482

To help users determine domains, display the domain indices used by the
kernel in sysfs.

 $ cat /sys/bus/event_source/devices/hv_24x7/interface/domains
 1: Physical Chip
 2: Physical Core
 3: VCPU Home Core
 4: VCPU Home Chip
 5: VCPU Home Node
 6: VCPU Remote Node

Signed-off-by: Sukadev Bhattiprolu <email address hidden>
Signed-off-by: Michael Ellerman <email address hidden>
(cherry picked from commit d34171e88aeed4a99c00c7f2af3d5c553e7a4972)
Signed-off-by: Tim Gardner <email address hidden>
Acked-by: Seth Forshee <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Luis Henriques <email address hidden>

4bf66e9... by Sukadev Bhattiprolu <email address hidden>

powerpc/perf/hv-24x7: Display change in counter values

BugLink: http://bugs.launchpad.net/bugs/1560482

For 24x7 counters, perf displays the raw value of the 24x7 counter, which
is a monotonically increasing value.

 perf stat -C 0 -e \
  'hv_24x7/HPM_0THRD_NON_IDLE_CCYC__PHYS_CORE,core=1/' \
  sleep 1

 Performance counter stats for 'CPU(s) 0':

     9,105,403,170 hv_24x7/HPM_0THRD_NON_IDLE_CCYC__PHYS_CORE,core=1/

       0.000425751 seconds time elapsed

In the typical usage of 'perf stat' this counter value is not as useful
as the _change_ in the counter value over the duration of the application.

Have h_24x7_event_init() set the event's prev_count to the raw value of
the 24x7 counter at the time of initialization. When the application
terminates, hv_24x7_event_read() will compute the change in value and
report to the perf tool. Similarly, for the transaction interface, clear
the event count to 0 at the beginning of the transaction.

 perf stat -C 0 -e \
  'hv_24x7/HPM_0THRD_NON_IDLE_CCYC__PHYS_CORE,core=1/' \
  sleep 1

 Performance counter stats for 'CPU(s) 0':

           245,758 hv_24x7/HPM_0THRD_NON_IDLE_CCYC__PHYS_CORE,core=1/

       1.006366383 seconds time elapsed

Signed-off-by: Sukadev Bhattiprolu <email address hidden>
Signed-off-by: Michael Ellerman <email address hidden>
(cherry picked from commit 2b206ee6b0df03a89783c6a9ada363122f918800)
Signed-off-by: Tim Gardner <email address hidden>
Acked-by: Seth Forshee <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Luis Henriques <email address hidden>

7363554... by Sukadev Bhattiprolu <email address hidden>

powerpc/perf/hv-24x7: Fix usage with chip events.

BugLink: http://bugs.launchpad.net/bugs/1560482

24x7 counters can belong to different domains (core, chip, virtual CPU
etc). For events in the 'chip' domain, sysfs entry currently looks like:

 $ cd /sys/bus/event_source/devices/hv_24x7/events
 $ cat PM_XLINK_CYCLES__PHYS_CHIP
 domain=0x1,offset=0x230,core=?,lpar=0x0

where the required parameter, 'core=?' is specified with perf as:

 perf stat -C 0 -e hv_24x7/PM_XLINK_CYCLES__PHYS_CHIP,core=1/ \
  /bin/true

This is inconsistent in that 'core' is a required parameter for a chip
event. Instead, have the the sysfs entry display 'chip=?' for chip
events:

 $ cd /sys/bus/event_source/devices/hv_24x7/events
 $ cat PM_XLINK_CYCLES__PHYS_CHIP
 domain=0x1,offset=0x230,chip=?,lpar=0x0

We also need to add a 'chip' entry in the sysfs format directory:

 $ ls /sys/bus/event_source/devices/hv_24x7/format
 chip core domain lpar offset vcpu
 ^^^^
 (new)

so the perf tool can automatically check usage and format the chip
parameter correctly:

 $ perf stat -C 0 -v -e hv_24x7/PM_XLINK_CYCLES__PHYS_CHIP/ \
  /bin/true
 Required parameter 'chip' not specified
 invalid or unsupported event: 'hv_24x7/PM_XLINK_CYCLES__PHYS_CHIP/'

 $ perf stat -C 0 -v -e hv_24x7/PM_XLINK_CYCLES__PHYS_CHIP,chip=1/ \
  /bin/true
 hv_24x7/PM_XLINK_CYCLES__PHYS_CHIP,chip=1/: 0 6628908 6628908

  Performance counter stats for 'CPU(s) 0':

          0 hv_24x7/PM_XLINK_CYCLES__PHYS_CHIP,chip=1/

     0.006606970 seconds time elapsed

Signed-off-by: Sukadev Bhattiprolu <email address hidden>
Signed-off-by: Michael Ellerman <email address hidden>
(cherry picked from commit e5a5886d7ae32b7afebfffecca340e466e4be2d1)
Signed-off-by: Tim Gardner <email address hidden>
Acked-by: Seth Forshee <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Luis Henriques <email address hidden>

b7fc9e8... by rostedt

ftrace/x86_32: Set ftrace_stub to weak to prevent gcc from using short jumps to it

BugLink: http://bugs.launchpad.net/bugs/1655040

With new binutils, gcc may get smart with its optimization and change a jmp
from a 5 byte jump to a 2 byte one even though it was jumping to a global
function. But that global function existed within a 2 byte radius, and gcc
was able to optimize it. Unfortunately, that jump was also being modified
when function graph tracing begins. Since ftrace expected that jump to be 5
bytes, but it was only two, it overwrote code after the jump, causing a
crash.

This was fixed for x86_64 with commit 8329e818f149, with the same subject as
this commit, but nothing was done for x86_32.

Cc: <email address hidden>
Fixes: d61f82d06672 ("ftrace: use dynamic patching for updating mcount calls")
Reported-by: Colin Ian King <email address hidden>
Tested-by: Colin Ian King <email address hidden>
Signed-off-by: Steven Rostedt <email address hidden>
(cherry picked from commit 847fa1a6d3d00f3bdf68ef5fa4a786f644a0dd67)
Signed-off-by: Colin Ian King <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Signed-off-by: Luis Henriques <email address hidden>

cba0dd1... by Thadeu Lima de Souza Cascardo

UBUNTU: [Debian] consider renames in gen-auto-reconstruct

Recent git versions have changed the rename detection to default when
using git-diff. Previous behavior would allow the reconstruct script to
remove the renamed files, which are added in the diff, but not removed.

Using --no-renames option will revert to the previous behavior when
using those recent git versions.

Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Signed-off-by: Luis Henriques <email address hidden>

9861ea8... by Alastair D'Silva

crypto: vmx - Convert to CPU feature based module autoloading

BugLink: http://bugs.launchpad.net/bugs/1651322

This patch utilises the GENERIC_CPU_AUTOPROBE infrastructure
to automatically load the vmx_crypto module if the CPU supports
it.

Signed-off-by: Alastair D'Silva <email address hidden>
Acked-by: Herbert Xu <email address hidden>
Signed-off-by: Michael Ellerman <email address hidden>
(back ported from commit ccf5c442a1b82bf74105d72416e069607353cb82)
Signed-off-by: Tim Gardner <email address hidden>

Conflicts:
 drivers/crypto/vmx/Kconfig
Acked-by: Seth Forshee <email address hidden>
Acked-by: John Donnelly <email address hidden>
Signed-off-by: Luis Henriques <email address hidden>

10bc605... by Alastair D'Silva

powerpc: Add module autoloading based on CPU features

BugLink: http://bugs.launchpad.net/bugs/1651322

This patch provides the necessary infrastructure to allow drivers
to be automatically loaded via udev. It implements the minimum
required to be able to use module_cpu_feature_match() to trigger
the GENERIC_CPU_AUTOPROBE mechanisms.

The features exposed are a mirror of the cpu_user_features
(converted to an offset from a mask). This decision was made to
ensure that the behavior between features for module loading and
userspace are consistent.

Signed-off-by: Alastair D'Silva <email address hidden>
[mpe: Only define the bits we currently need]
Signed-off-by: Michael Ellerman <email address hidden>

(back ported from commit 4a1202765ddf4e5bb3143c0a859ee37f8fcf9b85)
Signed-off-by: Tim Gardner <email address hidden>

Conflicts:
 arch/powerpc/Kconfig
Acked-by: Seth Forshee <email address hidden>
Acked-by: John Donnelly <email address hidden>
Signed-off-by: Luis Henriques <email address hidden>