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

[Hartmut Birr]

Hi,

you must change all position where a kernel stack is initialized:
- In multiboot.S is setup the initial stack
- In tss.c is setup the tss with the initial stack
- In w32call.c is setup a new kernel stack for the callback function.
- In kthread.c are setup some values on the top of the stack
- In bthread.S starts the execution of a new thread

It seems that you have changed only the last two points. The size of the
stack must not be changed.

- Hartmut


>   -----Original Message-----
>  From: ros-dev-bounces(a)reactos.com 
>  [mailto:[e-mail]] On Behalf Of Anich Gregor
>  Sent: Saturday, October 16, 2004 1:52 PM
>  To: ros-dev(a)reactos.com
>  Subject: Re: [ros-dev] Kernel-mode stack layout (FPU save 
>  area, trap frames,etc.)
>  
>  
>  Hello!
>  
>  I have tried to get some initial FPU save code working the 
>  last few days, but 
>  it always crashed on fsave or after frstor (math-fault)... I 
>  tried to reseve 
>  an FX_SAVE_AREA on top of the kernel stack by changing 
>  Ke386InitThreadWithContext to decrement the kernel stack 
>  pointer by sizeof 
>  (FX_SAVE_AREA) and changing the PsBeginThreadWithContext (in 
>  bthread.S) to 
>  not pop (frstor + decl esp) a FLOATING_AREA from the initial 
>  stack, so the 
>  FX_SAVE_AREA which is at the top of the stack should not be 
>  touched since the 
>  stack grows downwards, but it got either overwritten at some point or 
>  InitialThread in KTHREAD changes from time to time... Do you 
>  know if I should 
>  change the allocation size for the stack to MM_STACK_SIZE + sizeof 
>  (FX_SAVE_AREA) and use InitialThread instead of InitialThread 
>  - sizeof 
>  (FX_SAVE_AREA) for the FX_SAVE_AREA?
>  
>   - blight
>  
>  On Friday 15 October 2004 19:02, Hartmut Birr wrote:
> >   Hi,
> >
> >  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. 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. 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.
> >
> >  - Hartmut
> >
> >  > -----Original Message-----
> >  > From: ros-dev-bounces(a)reactos.com
> >  > [mailto:[e-mail]] On Behalf Of KJK::Hyperion
> >  > Sent: Wednesday, October 13, 2004 8:13 AM
> >  > To: ros-dev(a)reactos.com
> >  > Subject: [ros-dev] Kernel-mode stack layout (FPU save area,
> >  > trap frames,etc.)
> >  >
> >  >
> >  > I've finally taken the time to write it all down:
> >  >
> >  >  
>  <http://mok.lvcm.com/cgi-bin/reactos/roswiki?KernelModeStackLayout>
> > >  
> > >  Let me know if you see any mistakes or omissions 
> >  
> _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.com
>  http://reactos.com:8080/mailman/listinfo/ros-dev
>