linux-toradex.git/arch/powerpc, branch v4.4.89

powerpc: Fix DAR reporting when alignment handler faults

2017-09-27T09:00:14+00:00

commit f9effe925039cf54489b5c04e0d40073bb3a123d upstream.

Anton noticed that if we fault part way through emulating an unaligned
instruction, we don't update the DAR to reflect that.

The DAR value is eventually reported back to userspace as the address
in the SEGV signal, and if userspace is using that value to demand
fault then it can be confused by us not setting the value correctly.

This patch is ugly as hell, but is intended to be the minimal fix and
back ports easily.

Signed-off-by: Michael Ellerman 
Reviewed-by: Paul Mackerras 
Signed-off-by: Greg Kroah-Hartman

Revert "powerpc/numa: Fix percpu allocations to be NUMA aware"

2017-08-07T02:19:40+00:00

This reverts commit 8c92870bdbf20b5fa5150a2c8bf53ab498516b24 which is
commit ba4a648f12f4cd0a8003dd229b6ca8a53348ee4b upstream.

Michal Hocko writes:

JFYI. We have encountered a regression after applying this patch on a
large ppc machine. While the patch is the right thing to do it doesn't
work well with the current vmalloc area size on ppc and large machines
where NUMA nodes are very far from each other. Just for the reference
the boot fails on such a machine with bunch of warning preceeding it.
See http://lkml.kernel.org/r/20170724134240.GL25221@dhcp22.suse.cz

It seems the right thing to do is to enlarge the vmalloc space on ppc
but this is not the case in the upstream kernel yet AFAIK. It is also
questionable whether that is a stable material but I will decision on
you here.

We have reverted this patch from our 4.4 based kernel.

Newer kernels do not have enlarged vmalloc space yet AFAIK so they won't
work properly eiter. This bug is quite rare though because you need a
specific HW configuration to trigger the issue - namely NUMA nodes have
to be far away from each other in the physical memory space.

Cc: Michal Hocko 
Cc: Michael Ellerman 
Cc: Nicholas Piggin 
Signed-off-by: Greg Kroah-Hartman

KVM: PPC: Book3S HV: Save/restore host values of debug registers

2017-08-07T02:19:39+00:00

commit 7ceaa6dcd8c6f59588428cec37f3c8093dd1011f upstream.

At present, HV KVM on POWER8 and POWER9 machines loses any instruction
or data breakpoint set in the host whenever a guest is run.
Instruction breakpoints are currently only used by xmon, but ptrace
and the perf_event subsystem can set data breakpoints as well as xmon.

To fix this, we save the host values of the debug registers (CIABR,
DAWR and DAWRX) before entering the guest and restore them on exit.
To provide space to save them in the stack frame, we expand the stack
frame allocated by kvmppc_hv_entry() from 112 to 144 bytes.

[paulus@ozlabs.org - Adjusted stack offsets since we aren't saving
 POWER9-specific registers.]

Fixes: b005255e12a3 ("KVM: PPC: Book3S HV: Context-switch new POWER8 SPRs", 2014-01-08)
Signed-off-by: Paul Mackerras 
Signed-off-by: Greg Kroah-Hartman

KVM: PPC: Book3S HV: Reload HTM registers explicitly

2017-08-07T02:19:39+00:00

Commit 46a704f8409f ("KVM: PPC: Book3S HV: Preserve userspace HTM
state properly", 2017-06-15) added code which assumes that the kernel
is able to handle a TM (transactional memory) unavailable interrupt
from userspace by reloading the TM-related registers and enabling TM
for the process.  That ability was added in the 4.9 kernel; earlier
kernel versions simply panic on getting the TM unavailable interrupt.

Since commit 46a704f8409f has been backported to the 4.4 stable tree
as commit 824b9506e4f2, 4.4.75 and subsequent versions are vulnerable
to a userspace-triggerable panic.

This patch fixes the problem by explicitly reloading the TM-related
registers before returning to userspace, rather than disabling TM
for the process.

Commit 46a704f8409f also failed to enable TM for the kernel, leading
to a TM unavailable interrupt in the kernel, causing an oops.  This
fixes that problem too, by enabling TM before accessing the TM
registers.  That problem is fixed upstream by the patch "KVM: PPC:
Book3S HV: Enable TM before accessing TM registers".

Fixes: 824b9506e4f2 ("KVM: PPC: Book3S HV: Preserve userspace HTM state properly")
Signed-off-by: Paul Mackerras 
Signed-off-by: Greg Kroah-Hartman

KVM: PPC: Book3S HV: Restore critical SPRs to host values on guest exit

2017-08-07T02:19:39+00:00

commit 4c3bb4ccd074e1a0552078c0bf94c662367a1658 upstream.

This restores several special-purpose registers (SPRs) to sane values
on guest exit that were missed before.

TAR and VRSAVE are readable and writable by userspace, and we need to
save and restore them to prevent the guest from potentially affecting
userspace execution (not that TAR or VRSAVE are used by any known
program that run uses the KVM_RUN ioctl).  We save/restore these
in kvmppc_vcpu_run_hv() rather than on every guest entry/exit.

FSCR affects userspace execution in that it can prohibit access to
certain facilities by userspace.  We restore it to the normal value
for the task on exit from the KVM_RUN ioctl.

IAMR is normally 0, and is restored to 0 on guest exit.  However,
with a radix host on POWER9, it is set to a value that prevents the
kernel from executing user-accessible memory.  On POWER9, we save
IAMR on guest entry and restore it on guest exit to the saved value
rather than 0.  On POWER8 we continue to set it to 0 on guest exit.

PSPB is normally 0.  We restore it to 0 on guest exit to prevent
userspace taking advantage of the guest having set it non-zero
(which would allow userspace to set its SMT priority to high).

UAMOR is normally 0.  We restore it to 0 on guest exit to prevent
the AMR from being used as a covert channel between userspace
processes, since the AMR is not context-switched at present.

[paulus@ozlabs.org - removed IAMR bits that are only needed on POWER9;
 adjusted FSCR save/restore for lack of fscr field in thread_struct.]

Fixes: b005255e12a3 ("KVM: PPC: Book3S HV: Context-switch new POWER8 SPRs", 2014-01-08)
Signed-off-by: Paul Mackerras 
Signed-off-by: Greg Kroah-Hartman

KVM: PPC: Book3S HV: Context-switch EBB registers properly

2017-08-07T02:19:39+00:00

commit ca8efa1df1d15a1795a2da57f9f6aada6ed6b946 upstream.

This adds code to save the values of three SPRs (special-purpose
registers) used by userspace to control event-based branches (EBBs),
which are essentially interrupts that get delivered directly to
userspace.  These registers are loaded up with guest values when
entering the guest, and their values are saved when exiting the
guest, but we were not saving the host values and restoring them
before going back to userspace.

On POWER8 this would only affect userspace programs which explicitly
request the use of EBBs and also use the KVM_RUN ioctl, since the
only source of EBBs on POWER8 is the PMU, and there is an explicit
enable bit in the PMU registers (and those PMU registers do get
properly context-switched between host and guest).  On POWER9 there
is provision for externally-generated EBBs, and these are not subject
to the control in the PMU registers.

Since these registers only affect userspace, we can save them when
we first come in from userspace and restore them before returning to
userspace, rather than saving/restoring the host values on every
guest entry/exit.  Similarly, we don't need to worry about their
values on offline secondary threads since they execute in the context
of the idle task, which never executes in userspace.

Fixes: b005255e12a3 ("KVM: PPC: Book3S HV: Context-switch new POWER8 SPRs", 2014-01-08)
Signed-off-by: Paul Mackerras 
Signed-off-by: Greg Kroah-Hartman

powerpc/pseries: Fix of_node_put() underflow during reconfig remove

2017-08-07T02:19:39+00:00

commit 4fd1bd443e80b12f0a01a45fb9a793206b41cb72 upstream.

As for commit 68baf692c435 ("powerpc/pseries: Fix of_node_put()
underflow during DLPAR remove"), the call to of_node_put() must be
removed from pSeries_reconfig_remove_node().

dlpar_detach_node() and pSeries_reconfig_remove_node() both call
of_detach_node(), and thus the node should not be released in both
cases.

Fixes: 0829f6d1f69e ("of: device_node kobject lifecycle fixes")
Signed-off-by: Laurent Vivier 
Reviewed-by: David Gibson 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

powerpc/asm: Mark cr0 as clobbered in mftb()

2017-07-27T22:06:05+00:00

commit 2400fd822f467cb4c886c879d8ad99feac9cf319 upstream.

The workaround for the CELL timebase bug does not correctly mark cr0 as
being clobbered. This means GCC doesn't know that the asm block changes cr0 and
might leave the result of an unrelated comparison in cr0 across the block, which
we then trash, leading to basically random behaviour.

Fixes: 859deea949c3 ("[POWERPC] Cell timebase bug workaround")
Signed-off-by: Oliver O'Halloran 
[mpe: Tweak change log and flag for stable]
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

powerpc: Fix emulation of mfocrf in emulate_step()

2017-07-27T22:06:05+00:00

commit 64e756c55aa46fc18fd53e8f3598b73b528d8637 upstream.

From POWER4 onwards, mfocrf() only places the specified CR field into
the destination GPR, and the rest of it is set to 0. The PowerPC AS
from version 3.0 now requires this behaviour.

The emulation code currently puts the entire CR into the destination GPR.
Fix it.

Fixes: 6888199f7fe5 ("[POWERPC] Emulate more instructions in software")
Signed-off-by: Anton Blanchard 
Acked-by: Naveen N. Rao 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

powerpc: Fix emulation of mcrf in emulate_step()

2017-07-27T22:06:05+00:00

commit 87c4b83e0fe234a1f0eed131ab6fa232036860d5 upstream.

The mcrf emulation code was using the CR field number directly as the shift
value, without taking into account that CR fields are numbered from 0-7 starting
at the high bits. That meant it was looking at the CR fields in the reverse
order.

Fixes: cf87c3f6b647 ("powerpc: Emulate icbi, mcrf and conditional-trap instructions")
Signed-off-by: Anton Blanchard 
Acked-by: Naveen N. Rao 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman