Context switching and FPU

[matute81]

Hello everybody,
this is my first post, I hope this is the right forum section for my question.
I'm developing a kernel, I didn't use FPU in my kernel, until yesterday.
So I try to initialize the FPU with this code and it seems to work because I'm able to execute floating point operation:

Code: Select all

FUNCTION FpuInit
  push eax
  mov  eax, cr0
  and  eax, 0x080000011
  or   eax, 0x050022
  mov  cr0, eax
  clts
  fninit
  pop  eax
ENDFUNC FpuInit

My problem is in context switching. After this initizialization my scheduling doesn't work more.
I use a far jump to TSS selector to schedule a task and it works pretty good until yesterday
I don't receive any exception or errors, context switching simply doesn't work.
Could someone help me or give me a suggestion?
Thank you.

Daniele

[Combuster]

Why are you enabling alignment checking and kernel write-protect? Why must TS be cleared twice? Why are you modifying a ton of reserved bits?

[JamesM]

Hi,

Moved to OS development.

You say "doesn't work" - what are the symptoms?

James

[JamesM]

I can see why write-protect is enabled (copy-on write, yes OP?), but it does seem like you're ANDing with the wrong flag. Did you mean 0x80000011 (Protected mode, Kernel WP, Paging enabled) ?

[matute81]

Why are you enabling alignment checking and kernel write-protect? Why must TS be cleared twice? Why are you modifying a ton of reserved bits?

I don't modify any reserved bits!
I'm only interested to clear EM and set MP and NE ok?
I clear TS twice because I read somewhere that it's better to do this, maybe it's not, but anyway this is not the point! I mean that I'd like to know how FPU and context switching are linked.
That's all.

[matute81]

I can see why write-protect is enabled (copy-on write, yes OP?), but it does seem like you're ANDing with the wrong flag. Did you mean 0x80000011 (Protected mode, Kernel WP, Paging enabled) ?

Yes JamesM, I mean 0x80000011, but I use NASM so I must write 0x080000011!
The symptom is: kernel doesn't schedule the first task (I implemented a sort of sequential multitasking, and it works until I decide to use FPU!). I've no error, simply the kernel stop the execution like it enters in infinite loop, I'm sorry i don't know I can exactly explain that in english

[qw]

Yes JamesM, I mean 0x80000011, but I use NASM so I must write 0x080000011!

???

[matute81]

Yes JamesM, I mean 0x80000011, but I use NASM so I must write 0x080000011!

???

Sorry I made a mistake, I copy a wrong version of my code.
I mean 0x80000011, and with the previous post I mean that for NASM an hex constant must be for example 080000011h. Delete the previous post sorry!

Anyway this is not the point, there is no differences between 0x080000011 and 0x80000011.
I think that initialization works good, but task switching not!

[gerryg400]

I've no error, simply the kernel stop the execution like it enters in infinite loop

Do you have an IDT set up ? Is it possible you have entered a trap handler ?

Also when you

Code: Select all

  and  eax, 0x080000011
  or   eax, 0x050022
  

You are clearing bit 28. Bit 28 is reserved. You should write the same value that you read. The same applies to many bits.

To clear EM

Code: Select all

  and  eax, 0xfffffffb

To set MP and NE

Code: Select all

  or  eax, 0x22

[matute81]

Do you have an IDT set up ? Is it possible you have entered a trap handler ?

You are clearing bit 28. Bit 28 is reserved. You should write the same value that you read. The same applies to many bits.

Ok I made a mistake with bit 28. Thank you, I rectified it. But about I leave all other bits how they were, because my CR0 after all settings is 0x8001003B, after FPU initialization is 0x80010033.
I have an IDT.
I made a little bit more of debug and I think that kernel actually jump to first task but when the task calls his first API (I use correctly sysenter and sysexit for system calls) there is a problem, but I don't understand why.
If I remove FPU initialization kernel works correctly!

[matute81]

Sorry guys,
I'm completely idiot!
Why nobody told me that I forgot "ret" at the end of my assembly function??
Ok, now my kernel works good.

But I have an answer, must I do FPU context switch like described in Intel software dev man?
"The processor does not automatically save the context of the x87 FPU, XMM, and MXCSR registers on a task switch. Instead, it sets the TS flag, which causes the processor to raise an #NM exception whenever it encounters an x87 FPU/MMX/SSE /SSE2/SSE3/SSSE3/SSE4 instruction in the instruction stream for the new task (with the exception of the instructions listed above).
The fault handler for the #NM exception can then be used to clear the TS flag (with the CLTS instruction) and save the context of the x87 FPU, XMM, and MXCSR registers.
If the task never encounters an x87 FPU/MMX/SSE/SSE2/SSE3//SSSE3/SSE4 instruction; the x87 FPU/MMX/SSE/SSE2/ SSE3/SSSE3/SSE4 context is never saved."

Is there a more simple way?
I need to use FXSAVE and FXRSTOR inside my "fault handler", isn't it?

I'm really sorry for my previous stupid error!

[JamesM]

Is there a more simple way?

Nope. You have to FXSAVE/FXRESTOR whenever you switch tasks and that task has used the FPU.

[egos]

Is there a more simple way?
I need to use FXSAVE and FXRSTOR inside my "fault handler", isn't it?

It's simple. You can clean TS during task switching but it is not effective. You would use FXSAVE/FXRSTOR but only after "clts" instruction. It's seems to me that Intel manual has error in action sequence.

[JamesM]

Is there a more simple way?
I need to use FXSAVE and FXRSTOR inside my "fault handler", isn't it?

It's simple. You can clean TS during task switching but it is not effective. You would use FXSAVE/FXRSTOR but only after "clts" instruction. It's seems to me that Intel manual has error in action sequence.

Surely that wouldn't cause the FPU state to be saved, allowing it to be trashed by the next task?

[egos]

I don't understand your question.