OSDev.org

It is possible to change eip not using tss-based threads implemantation?
i'm curious how context switching(of kthreads and user processes) is implemented in modern os'es - i've heard that tss is obsolute, isn't it?

TSS are not more used than 10 years ago and techniques to switch tasks without a TSS exists since years.

Basically, you push thread state on stack, keep a snapshot of the stack pointer in the 'thread control block' and then reload the stack pointer from the TCB of another thread.

The trick for changing EIP is that the return address stored on the leaving stack is not the same as the return address previously stored on the incoming stack, thus when the function will issue "RET", it will branch back to the operations of the incoming thread, leaving the outgoing thread alone ...

RMX wrote:It is possible to change eip not using tss-based threads implemantation?

Yes, easily. The traditional instruction for setting the EIP is called JMP, although most task switches do it with a stack load.

RMX wrote:i'm curious how context switching(of kthreads and user processes) is implemented in modern os'es - i've heard that tss is obsolute, isn't it?

Answering your second question first, no, not exactly. In fact, there's a 64-bit format TSS for long mode. However, you can't do task switching in hardware like you can in legacy modes. Check the x86-64 manuals for information about 64-bit TSS, LTR, and such.

But this is irrelevant in any case. When you're writing support for IA-32 processors into your OS, what x86-64 processors do is irrelevant to anything you do. At the level of coding you're talking about, there's simply no such thing as portability. Whether 68030 processors have a TSS or not is no more or less relevant to the question at hand. Since the IA-32 CPUID features bits don't include a bit for TSS support, they can't ever turn it off on future processors, so the TSS is not and in fact cannot become obsolete on IA-32 machines. It will always be supported on that processor family.

As far as how context switching is implemented in modern OS's, especially when you bring threads into the question, the answer would be "lots of different ways", varying greatly depending on the resources of the underlying processor. For example, on some OSes on some processors, they don't even save registers to memory during context switches (in most cases) -- they change a base register pointer on each context switch which causes seperate processes to have their own sets of registers. But then these processors were designed for multitasking and have ridiculous numbers of registers, and restrict programs to a subset of them. Some operating systems use software based task switching. Some do it all in user space. Unless you have a narrow subset of modern operating systems you want to talk about, there's probably a few dozen answers to your question...

The trick for changing EIP is that the return address stored on the leaving stack is not the same as the return address previously stored on the incoming stack, thus when the function will issue "RET", it will branch back to the operations of the incoming thread, leaving the outgoing thread alone ...

But who or what lives eip on stack of task to be switched to?
Scheduler routine, if so it have to modify previously saved context of next task to be executed.
Secondly, what if stack isn't present in memory - how to prevent from such paging error?
BTW: Am I to update ss and esp regs in TSS assigned to each of cpus ? I heard it is needed?

But who or what lives eip on stack of task to be switched to?

whatever has called the switch code the last time ... you really don't need to care as long as only *one* function is used to do the switch. Most likely, you'll have something like

<ret info to some user process>
<stack frame for the interrupt handler>
<stack frames for some C code>
<stack frame for the StackSwitch function>

what if stack isn't present in memory - how to prevent from such paging error?

At kernel level, this is simply not allowed. Any fault will be processed by the handler on the kernel stack, so that stack *must* be present. Or you may chose a design in which exception that catch such events have dedicated TSS with ever-present stack space, etc.

Before returning to the user-land, you"ll have to make sure the TSS.ESP0 and TSS.SS0 values have been updated to point towards the kernel stack of the newly set up thread.