On Intel bits 0x2 (transaction may succeed on a retry) and 0x4 (abort is due to a memory conflict) are tested and if any is set lock is retried. The organization of bits in 'abort_status_Reg':

  // EAX register bit position Meaning
  // 0 Set if abort caused by XABORT instruction.
  // 1 If set, the transaction may succeed on a retry. This bit is always clear if bit 0 is set.
  // 2 Set if another logical processor conflicted with a memory address that was part of the transaction that aborted.
  
It happens that on Intel, contrary to Power, if abort_status_Reg bit 0 (caused by XABORT instruction) is set it implies that bit 1 (0x2) is not set. In other words, an abort due to a xabort instruction (intentional) never sets bit 1 (0x2), hence the lock is never retried.

However, on Power bit 1 (0x2 mask) (transaction may succeed on a retry) is mapped to the persistent bit tm_failure_persistent (tho meaning is inverted). So on Power if bit 1 is clear it means the failure is not persistent and so we can retry. But on Power the intentional abort is caused by instruction 'tabort. r0' which does not set the tm_failure_persistent bit, as operand == r0. As a result a deliberate abort on Intel implies "do not retry the lock", whilst on Power it implies "do retry the lock".

As a consequence on Power a retry on deliberate abort, for instance when RTMRetryCount=1, causes 3 aborts instead of 2 (the first failure + 1 additional done in rtm_retry_lock_on_busy()). On Power we have the first failure + 1 (done wrongly iby rtm_retry_lock_on_abort()) + 1 (done correctly as on Intel by rtm_retry_lock_on_busy()).

A simple solution is to check the tm_abort bit (31) to verify if the abort was intentional.