[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 at reactos.com 
> [mailto:ros-dev-bounces at reactos.com] On Behalf Of Anich Gregor
> Sent: Saturday, October 16, 2004 1:52 PM
> To: ros-dev at 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 at reactos.com
> > > [mailto:ros-dev-bounces at reactos.com] On Behalf Of KJK::Hyperion
> > > Sent: Wednesday, October 13, 2004 8:13 AM
> > > To: ros-dev at 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 at reactos.com
> http://reactos.com:8080/mailman/listinfo/ros-dev
>