RE: [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)