Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 11 7月, 2015 1 次提交
  3. 19 6月, 2015 1 次提交
    • S
      powerpc/tm: Abort syscalls in active transactions · b4b56f9e
      由 Sam bobroff 提交于 
      This patch changes the syscall handler to doom (tabort) active
transactions when a syscall is made and return very early without
performing the syscall and keeping side effects to a minimum (no CPU
accounting or system call tracing is performed). Also included is a
new HWCAP2 bit, PPC_FEATURE2_HTM_NOSC, to indicate this
behaviour to userspace.

Currently, the system call instruction automatically suspends an
active transaction which causes side effects to persist when an active
transaction fails.

This does change the kernel's behaviour, but in a way that was
documented as unsupported.  It doesn't reduce functionality as
syscalls will still be performed after tsuspend; it just requires that
the transaction be explicitly suspended.  It also provides a
consistent interface and makes the behaviour of user code
substantially the same across powerpc and platforms that do not
support suspended transactions (e.g. x86 and s390).

Performance measurements using
http://ozlabs.org/~anton/junkcode/null_syscall.c indicate the cost of
a normal (non-aborted) system call increases by about 0.25%.
Signed-off-by: NSam Bobroff <sam.bobroff@au1.ibm.com>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      b4b56f9e
  5. 07 6月, 2015 1 次提交
  7. 03 6月, 2015 1 次提交
  9. 30 4月, 2015 1 次提交
    • M
      Revert "powerpc/tm: Abort syscalls in active transactions" · 68fc378c
      由 Michael Ellerman 提交于 
      This reverts commit feba4036.

Although the principle of this change is good, the implementation has a
few issues.

Firstly we can sometimes fail to abort a syscall because r12 may have
been clobbered by C code if we went down the virtual CPU accounting
path, or if syscall tracing was enabled.

Secondly we have decided that it is safer to abort the syscall even
earlier in the syscall entry path, so that we avoid the syscall tracing
path when we are transactional.

So that we have time to thoroughly test those changes we have decided to
revert this for this merge window and will merge the fixed version in
the next window.

NB. Rather than reverting the selftest we just drop tm-syscall from
TEST_PROGS so that it's not run by default.

Fixes: feba4036 ("powerpc/tm: Abort syscalls in active transactions")
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      68fc378c
  11. 11 4月, 2015 2 次提交
  13. 31 3月, 2015 1 次提交
  15. 08 10月, 2014 1 次提交
  17. 28 7月, 2014 1 次提交
    • A
      KVM: PPC: Remove 440 support · b2677b8d
      由 Alexander Graf 提交于 
      The 440 target hasn't been properly functioning for a few releases and
before I was the only one who fixes a very serious bug that indicates to
me that nobody used it before either.

Furthermore KVM on 440 is slow to the extent of unusable.

We don't have to carry along completely unused code. Remove 440 and give
us one less thing to worry about.
Signed-off-by: NAlexander Graf <agraf@suse.de>
      b2677b8d
  19. 05 6月, 2014 1 次提交
  21. 05 5月, 2014 1 次提交
  23. 27 8月, 2013 1 次提交
  25. 01 7月, 2013 1 次提交
  27. 01 6月, 2013 3 次提交
    • M
      powerpc/tm: Fix userspace stack corruption on signal delivery for active transactions · 2b3f8e87
      由 Michael Neuling 提交于 
      When in an active transaction that takes a signal, we need to be careful with
the stack.  It's possible that the stack has moved back up after the tbegin.
The obvious case here is when the tbegin is called inside a function that
returns before a tend.  In this case, the stack is part of the checkpointed
transactional memory state.  If we write over this non transactionally or in
suspend, we are in trouble because if we get a tm abort, the program counter
and stack pointer will be back at the tbegin but our in memory stack won't be
valid anymore.

To avoid this, when taking a signal in an active transaction, we need to use
the stack pointer from the checkpointed state, rather than the speculated
state.  This ensures that the signal context (written tm suspended) will be
written below the stack required for the rollback.  The transaction is aborted
becuase of the treclaim, so any memory written between the tbegin and the
signal will be rolled back anyway.

For signals taken in non-TM or suspended mode, we use the
normal/non-checkpointed stack pointer.

Tested with 64 and 32 bit signals
Signed-off-by: NMichael Neuling <mikey@neuling.org>
Cc: <stable@vger.kernel.org> # v3.9
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      2b3f8e87
    • M
      powerpc/tm: Abort on emulation and alignment faults · 6ce6c629
      由 Michael Neuling 提交于 
      If we are emulating an instruction inside an active user transaction that
touches memory, the kernel can't emulate it as it operates in transactional
suspend context.  We need to abort these transactions and send them back to
userspace for the hardware to rollback.

We can service these if the user transaction is in suspend mode, since the
kernel will operate in the same suspend context.

This adds a check to all alignment faults and to specific instruction
emulations (only string instructions for now).  If the user process is in an
active (non-suspended) transaction, we abort the transaction go back to
userspace allowing the HW to roll back the transaction and tell the user of the
failure.  This also adds new tm abort cause codes to report the reason of the
persistent error to the user.

Crappy test case here http://neuling.org/devel/junkcode/aligntm.cSigned-off-by: NMichael Neuling <mikey@neuling.org>
Cc: <stable@vger.kernel.org> # v3.9
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      6ce6c629
    • M
      powerpc/tm: Update cause codes documentation · 24b92375
      由 Michael Neuling 提交于 
      Signed-off-by: NMichael Neuling <mikey@neuling.org>
Cc: <stable@vger.kernel.org> # 3.9 only
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      24b92375
  29. 18 4月, 2013 2 次提交
  31. 15 2月, 2013 1 次提交
  33. 10 1月, 2013 1 次提交
  35. 15 11月, 2012 1 次提交
  37. 22 5月, 2012 1 次提交
  39. 14 5月, 2012 1 次提交
  41. 19 3月, 2012 1 次提交
  43. 23 2月, 2012 2 次提交
  45. 31 3月, 2011 1 次提交
  47. 23 3月, 2011 1 次提交
  49. 22 3月, 2011 1 次提交
  51. 17 3月, 2011 1 次提交
  53. 08 3月, 2011 1 次提交
  55. 31 1月, 2011 1 次提交
  57. 24 12月, 2010 1 次提交
  59. 29 11月, 2010 2 次提交
  61. 02 11月, 2010 1 次提交
  63. 23 10月, 2010 1 次提交
    • A
      USB: add USB EHCI support for MPC5121 SoC · 230f7ede
      由 Anatolij Gustschin 提交于 
      Extends FSL EHCI platform driver glue layer to support
MPC5121 USB controllers. MPC5121 Rev 2.0 silicon EHCI
registers are in big endian format. The appropriate flags
are set using the information in the platform data structure.
MPC83xx system interface registers are not available on
MPC512x, so the access to these registers is isolated in
MPC512x case. Furthermore the USB controller clocks
must be enabled before 512x register accesses which is
done by providing platform specific init callback.

The MPC512x internal USB PHY doesn't provide supply voltage.
For boards using different power switches allow specifying
DRVVBUS and PWR_FAULT signal polarity of the MPC5121 internal
PHY using "fsl,invert-drvvbus" and "fsl,invert-pwr-fault"
properties in the device tree USB nodes. Adds documentation
for this new device tree bindings.
Signed-off-by: NAnatolij Gustschin <agust@denx.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      230f7ede
  65. 13 10月, 2010 1 次提交
  67. 21 8月, 2010 1 次提交