[ros-dev] Kernel-mode stack layout (FPU save area, trap frames, etc.)

[KJK::Hyperion]

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)