ManyThreads
store thread state and fpu state in a memory frame
This allows to setup, investigate and migrate a thread state without a huge amount of system calls to query and change the state contents. Instead the frame can be mapped into the user-space for direct access. Simplifies trap handling a lot. Simplifies the handling of the machine-dependent variable size of the fpu state.
When registering the frame, the user specifies the offset and usable size inside the frame. The kernel has to check that this actually lies within the frame. If the machine-dependent fpu state would not fit, an error is returned. When the frame is revoked, the execution context has to be suspended before completing the revocation. This ensures that the memory is still usable by the kernel entry code.
The same frame may contain the invocation buffer for system calls and a ring buffer for efficent notification delivery.
xrstor throws a general protection fault if the mxcsr field has reserved bits not cleared. Exposing the FPU state to user space allows to manipulate this field. Thus, the kernel can get a GP exception when loading a user-modified FPU state.
Checking these values before xrstor does not help because parallel running threads can modify the value between check and xrstor. We could copy the complete FPU state into a kernel-private memory every time. However, the state can become quite large (4KiB). A more efficient alternative is to handle the GP fault correctly in the kernel just when it happens. It is sufficient to suspend the execution context as if the GP happened in user mode.