On Wed, Apr 27, 2016 at 03:25:59PM +0000, David Laight wrote:
From: Chris Smart
Sent: 26 April 2016 01:29
The copy paste facility introduced in POWER9 provides an optimised
mechanism for a userspace application to copy a cacheline. This is
provided by a pair of instructions, copy and paste, while a third,
cp_abort (copy paste abort), provides a clean up of the state in case of
a failure.
The copy instruction will read a 128 byte cacheline and store it in an
internal buffer. The subsequent paste instruction will store this
internal buffer to memory and set a CR field if the paste succeeds.
Since the state of the copy paste buffer is internal (and not
architecturally visible), in the unlikely event of a context switch, the
state cannot be stored and the paste should therefore fail.
The cp_abort instruction exists to fail and clean up any such
interrupted copy paste sequence and is to be called by the kernel as
part of the context switch. Doing so prevents data from a preceding copy
in one process leaking into the paste of another.
This code enables use of the cp_abort instruction if a supported
processor is detected.
In that case what actually completes the copy?
I think you'd need to be inside a 'restartable atomic sequence'
in which case the cp_abort need only be done when the/a RAS
block is detected.
Or have I missed something??
It's up to the userspace process that's doing the copy paste to check
the CR field after the paste to see whether it has succeeded. If it has
not succeeded, then the process can choose to re-do the copy and paste.
This is very similar to a lwarx stwcx where the user checks the CR after
the stwcx to verify whether it has succeeded.
Hope that makes sense.
-c
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
