At 19.02 15/10/2004, you wrote:
I think we need two floating save areas, one for user mode and one for kernel mode. The area for kernel mode is necessary because win32k and freetype are using the fpu. The kernel mode area is not necessary if we protect some function in win32k with KeSaveFloatingPointState/KeRestoreFloatingPointState.
I think kernel-mode components using the FPU on x86 are supposed to save the state themselves. Win32k actually uses a software implementation of fixed-point numbers (FLOATOBJ), though. FreeType isn't a problem, since we already have "enter FreeType" and "leave FreeType" functions in win32k, which at the moment acquire a mutex (FreeType isn't thread-safe), but could be extended to save the FPU state too (I'm not so cool about it, anyway. It all sounds very expensive)
The start of the areas should be calculate as a offset from the top of the kernel stack and not as offset from the user mode trap frame.
Offset from the user-mode trap frame is how Windows addresses it
The state of the fpu must be saved on a thread switch and if the fpu was used. At this point the start of the user mode trap frame is only known as an offset from the top of the stack.
Consider that the user-mode trap frame, in turn, is at a fixed offset from the stack base, since the FPU save area and the trap frame have a fixed size. And, at thread switch, you need to load the correct value for the ring 0 SS:ESP in the TSS, and this will be a fixed offset from the user-mode trap frame too (&TrapFrame->HardwareEsp, IIRC)