OSDev.org

When a thread switches into kernel mode I'm not sure how the kernel saves the thread's registers into the thread control block. How does the kernel mode thread run on the processor and use up the registers at the same time it is copying the user mode thread's registers to the TCB? Wouldn't that be impossible since only one thread can occupy the processor at a time?

Come on! It's not that difficult a problem, is it? You have, say, 15 registers that you want to save and you need to write a short assembler routine to do that. Try it.

If you have to change any registers in the routine then you save them first - in fact you've probably pushed some of them to the stack before you even got this far, and the new thread won't be using that stack, so when the thread restores the registers it can pop those ones. You could just save all the registers on the stack, and just save the stack pointer, rather than in a process structure, but that may not be the best solution for other reasons.

Hi,

icealys wrote:When a thread switches into kernel mode I'm not sure how the kernel saves the thread's registers into the thread control block. How does the kernel mode thread run on the processor and use up the registers at the same time it is copying the user mode thread's registers to the TCB? Wouldn't that be impossible since only one thread can occupy the processor at a time?

Normally the kernel saves the thread's registers on the stack, then does its thing. When a task switch occurs the kernel may just leave the thread's registers on the stack and switch stacks (typical if there's one kernel stack per thread) or could copy the thread's registers into a TCB (typical if there's one kernel stack per CPU).


Cheers,

Brendan

yeah i was just wondering how the kernel actually saves the registers...meaning...how the registers stay frozen in a certain state and then the kernel somehow runs on the processor while that user mode state is frozen in the registers...how could the user mode state be frozen on the processor while the kernel is running its own thread on the processor and saving that frozen state to the TCB?
Sorry if my question wasn't really clear before.

Hi,

icealys wrote:yeah i was just wondering how the kernel actually saves the registers...meaning...how the registers stay frozen in a certain state and then the kernel somehow runs on the processor while that user mode state is frozen in the registers...how could the user mode state be frozen on the processor while the kernel is running its own thread on the processor and saving that frozen state to the TCB?
Sorry if my question wasn't really clear before.

The kernel doesn't run on the processor while that user mode state is frozen in the registers. The kernel saves the user mode state (e.g. on the stack), so that there's no user mode state in the registers while the kernel is using them.


Cheers,

Brendan

when you say the kernel saves the user mode state(e.g. on the stack)...where does the kernel first copy the state from in order to put it on the stack? which brings me back to the original question...I thought that the state is inside the processor, then the kernel comes in and copies the state(registers) to the stack. Is this the case?

Hi,

icealys wrote:when you say the kernel saves the user mode state(e.g. on the stack)...where does the kernel first copy the state from in order to put it on the stack? which brings me back to the original question...I thought that the state is inside the processor, then the kernel comes in and copies the state(registers) to the stack. Is this the case?

The user mode state is in CPU registers. It's extremely easy to for the kernel to push values in CPU's registers (the user mode state) onto the stack.

For an example, see any documentation that describes the PUSHAD instruction (which pushes all of the general purpose register's contents onto the stack).


Cheers,

Brendan

Let me see if I understand this correctly. The user mode thread calls the kernel and the kernel copies the user mode stack into the kernel stack...this includes the stack pointer and the return address. Then the kernel copies the registers into the kernel mode stack. Is this correct? and if so would the return address be used to fill in the instruction pointer when it gets executed at a later time? I did some looking around on this site...http://stackoverflow.com/questions/1263 ... -internals ... and it sais that the instruction pointer and stack pointer are saved to the kernel mode stack. The only way I can think of the instruction pointer being saved is through the return address when it is saved on the call stack when the cpu is interrupted. I don't think the instruction pointer register would be saved by the kernel copying the register because the kernel would be an instruction itself using up the instruction pointer at that point.

Hi,

icealys wrote:Let me see if I understand this correctly. The user mode thread calls the kernel and the kernel copies the user mode stack into the kernel stack...this includes the stack pointer and the return address. Then the kernel copies the registers into the kernel mode stack. Is this correct?

Typically; user mode code calls the kernel and the CPU switches to the kernel's stack and puts the "return CS and EIP" (and possibly EFLAGS and other things) on the kernel's stack. Then the kernel's code saves whatever registers (containing user mode state) it's planning to use on the kernel's stack too.

When the kernel wants to return back to user mode it does the reverse of this (popping the values it put on the stack back into registers, and letting the CPU load the "return CS and EIP" during the switch back to user mode).

There's normally no need to copy anything from user mode stack to kernel stack (e.g. kernel API parameters passed in registers).

Of course in theory there's at least 15 different variations of this (call gate, interrupt gate, task gate, sysenter, syscall; each with different possibilities for parameter passing); but the basic idea is mostly the same.


Cheers,

Brendan

icealys wrote:The user mode thread calls the kernel and the kernel copies the user mode stack into the kernel stack.

No it doesn't. Why should it make a copy of something that is large and already has it's own bit of memory allocated?

this includes the stack pointer and the return address.

INT does that for you. You will have to look up how interrupts and exceptions work to see what they do to the stack.

Then the kernel copies the registers into the kernel mode stack.

This is the only thing the kernel has to do explicitly.

oh ok...so INT takes care of putting the instruction pointer and stack pointer on the kernel stack...thanks so much!