kernel.git/arch/powerpc/lib, branch linux-3.18.y

powerpc/lib: Fix off-by-one in alternate feature patching

2018-04-24T07:29:28Z

commit b8858581febb050688e276b956796bc4a78299ed upstream. When we patch an alternate feature section, we have to adjust any relative branches that branch out of the alternate section. But currently we have a bug if we have a branch that points to past the last instruction of the alternate section, eg: FTR_SECTION_ELSE 1: b 2f or 6,6,6 2: ALT_FTR_SECTION_END(...) nop This will result in a relative branch at 1 with a target that equals the end of the alternate section. That branch does not need adjusting when it's moved to the non-else location. Currently we do adjust it, resulting in a branch that goes off into the link-time location of the else section, which is junk. The fix is to not patch branches that have a target == end of the alternate section. Fixes: d20fe50a7b3c ("KVM: PPC: Book3S HV: Branch inside feature section") Fixes: 9b1a735de64c ("powerpc: Add logic to patch alternative feature sections") Cc: stable@vger.kernel.org # v2.6.27+ Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman

powerpc: Fix emulation of mfocrf in emulate_step()

2017-07-27T22:03:25Z

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:03:25Z

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

powerpc: Emulation support for load/store instructions on LE

2017-04-18T05:55:54Z

commit e148bd17f48bd17fca2f4f089ec879fa6e47e34c upstream. emulate_step() uses a number of underlying kernel functions that were initially not enabled for LE. This has been rectified since. So, fix emulate_step() for LE for the corresponding instructions. Reported-by: Anton Blanchard Signed-off-by: Ravi Bangoria Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman

powerpc: Implement emulation of string loads and stores

2014-09-25T13:14:52Z

The size field of the op.type word is now the total number of bytes to be loaded or stored. Signed-off-by: Paul Mackerras Signed-off-by: Michael Ellerman

powerpc: Emulate icbi, mcrf and conditional-trap instructions

2014-09-25T13:14:51Z

This extends the instruction emulation done by analyse_instr() and emulate_step() to handle a few more instructions that are found in the kernel. Signed-off-by: Paul Mackerras Signed-off-by: Michael Ellerman

powerpc: Split out instruction analysis part of emulate_step()

2014-09-25T13:14:51Z

This splits out the instruction analysis part of emulate_step() into a separate analyse_instr() function, which decodes the instruction, but doesn't execute any load or store instructions. It does execute integer instructions and branches which can be executed purely by updating register values in the pt_regs struct. For other instructions, it returns the instruction type and other details in a new instruction_op struct. emulate_step() then uses that information to execute loads, stores, cache operations, mfmsr, mtmsr[d], and (on 64-bit) sc instructions. The reason for doing this is so that the KVM code can use it instead of having its own separate instruction emulation code. Possibly the alignment interrupt handler could also use this. Signed-off-by: Paul Mackerras Signed-off-by: Michael Ellerman

powerpc: Make a bunch of things static

2014-09-25T13:14:41Z

Signed-off-by: Anton Blanchard Signed-off-by: Michael Ellerman

powerpc: Move lib symbol exports into arch/powerpc/lib/ppc_ksyms.c

2014-09-25T13:14:39Z

Move the lib symbol exports closer to their function definitions Signed-off-by: Anton Blanchard Signed-off-by: Michael Ellerman

powerpc: Add smp_mb()s to arch_spin_unlock_wait()

2014-08-13T05:13:27Z

Similar to the previous commit which described why we need to add a barrier to arch_spin_is_locked(), we have a similar problem with spin_unlock_wait(). We need a barrier on entry to ensure any spinlock we have previously taken is visibly locked prior to the load of lock->slock. It's also not clear if spin_unlock_wait() is intended to have ACQUIRE semantics. For now be conservative and add a barrier on exit to give it ACQUIRE semantics. Signed-off-by: Michael Ellerman Signed-off-by: Benjamin Herrenschmidt