summaryrefslogtreecommitdiff
path: root/elf.c
AgeCommit message (Expand)AuthorFilesLines
2010-11-10First bunch of rework, stil work in progressTobias Klauser1-0/+106
alue='7'>7space:mode:
authorCyril Bur <cyrilbur@gmail.com>2016-09-23 16:18:08 +1000
committerMichael Ellerman <mpe@ellerman.id.au>2016-10-04 16:43:05 +1100
commitdc16b553c949e81f37555777dc7bab66d78285a7 (patch)
tree232193ebddf36323a7611d5118e5bdad540edde5 /arch/powerpc
parent0e7736c6b806b24c693367196a076c78328ed742 (diff)
powerpc: Always restore FPU/VEC/VSX if hardware transactional memory in use
Comment from arch/powerpc/kernel/process.c:967: If userspace is inside a transaction (whether active or suspended) and FP/VMX/VSX instructions have ever been enabled inside that transaction, then we have to keep them enabled and keep the FP/VMX/VSX state loaded while ever the transaction continues. The reason is that if we didn't, and subsequently got a FP/VMX/VSX unavailable interrupt inside a transaction, we don't know whether it's the same transaction, and thus we don't know which of the checkpointed state and the ransactional state to use. restore_math() restore_fp() and restore_altivec() currently may not restore the registers. It doesn't appear that this is more serious than a performance penalty. If the math registers aren't restored the userspace thread will still be run with the facility disabled. Userspace will not be able to read invalid values. On the first access it will take an facility unavailable exception and the kernel will detected an active transaction, at which point it will abort the transaction. There is the possibility for a pathological case preventing any progress by transactions, however, transactions are never guaranteed to make progress. Fixes: 70fe3d9 ("powerpc: Restore FPU/VEC/VSX if previously used") Signed-off-by: Cyril Bur <cyrilbur@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Diffstat (limited to 'arch/powerpc')