Developer Forum

I have a naive question about how the context switch between user mode
and kernel mode happens in a live processor.

Allow me to illustrate my question with an example:

if (x == 0) }
printf("x is 0");
}

If you look at the above snippet of C-code, the printf function call
eventually causes the process to execute a jump into a memory location
deep inside the kernel.

How does the x86 processor know that this "process" is now executing
the "kernel" part of its algorithm and graciously switch back to
user-mode?

I understand the intent, and the software ramifications of such a
system (protecting the memory owned by somebody else's process on a
multi-user system, or even another process on the same machine). What I
dont understand is how the processor infers this in hardware.

Are there instructions to tell which parts of the memory are owned by
the kernel?

On DOS systems, things were pretty simple. You had interrupt service
routines, and if you didnt like what microsoft had coded up for the
keyboard routine, you wrote your owne routine and altered the table at
the location 0:0. I think the int instruction looked up the address of
the handler by multiplying the interrupt number (in hex) with 4, and
using this as an offset at 0:0

Thank you,
Rohit

Hello,


[snip]
[snip]

I assume you are dealing with the transition from "real" mode to
"protected" mode. In real mode the interrupt table was hard-wired
(actually microcoded) to address 0.

For protected mode, a group of registers was added to control the
system behavior. These registers are only accessible by the kernel
(ring 0). The relevant register is the interrupt descriptor table
register (IDTR). This register holds an address to the start of the
table. The table has an entry for each interrupt vector (for both
physical and software interrupts).

developer.intel.com used to be a good place to find the specs, but
everything has been reshuffled. A quick search brought up:
http://www.yqcomputer.com/
which is for the Pentium 4. The relevant manuals are volume 3 (system
programming guide).

Hope that helps!
Ned

In article < XXXX@XXXXX.COM >,
" XXXX@XXXXX.COM " < XXXX@XXXXX.COM > writes:
|>
|> > I have a naive question about how the context switch between user mode
|> > and kernel mode happens in a live processor.

No, it's not a naive question.

|> For protected mode, a group of registers was added to control the
|> system behavior. These registers are only accessible by the kernel
|> (ring 0). The relevant register is the interrupt descriptor table
|> register (IDTR). This register holds an address to the start of the
|> table. The table has an entry for each interrupt vector (for both
|> physical and software interrupts).

Similar remarks apply to all modern systems that I know of, and it's
a complete shambles.

I do not not know why it developed, but modern systems use a single
interrupt mechanism for half-a-dozen completely unrelated purposes,
from handling device I/O to TLB misses to signalling to emulating
floating-point to system calls. Naturally, the mechanism is very
poorly suited to most of them, and this causes a LOT of performance
and reliability problems.

Logically, a system call is just a function call into a piece of code
has an attached capability, but it ain't done like that (though it was
on a few systems).


Regards,
Nick Maclaren.

Well, OS use what processors provide, and it's not like x86 provides
dozens of methods for ring transition.


Actually modern operating systems (Windows XP, linux 2.6) on
modern x86 processors (PII+) do not use an interrupt for system
calls any more, but sysenter/syscall instructions.

MS

In article < XXXX@XXXXX.COM >,
XXXX@XXXXX.COM writes:

|>
|> Well, OS use what processors provide, and it's not like x86 provides
|> dozens of methods for ring transition.

That was and is my point.

|> > Logically, a system call is just a function call into a piece of code
|> > has an attached capability, but it ain't done like that (though it was
|> > on a few systems).
|>
|> Actually modern operating systems (Windows XP, linux 2.6) on
|> modern x86 processors (PII+) do not use an interrupt for system
|> calls any more, but sysenter/syscall instructions.

Well, my understanding is that those were implemented much like SVCs
were implemented on System/370 - i.e. the instructions work by
generating an interrupt!

I am not talking about the ISA here, but about the effect on the
CPU. It needs to be noted, however, that system calls are not the
most important ones to separate off the generic interrupt mechanism,
either on reliability or performance grounds.


Regards,
Nick Maclaren.

I think it's already been answered, but perhaps it might not be clear
where the answer is.

A user mode process, obviously, can *never* just turn itself on to
kernel mode. If it could turn kernel mode back on, then the user mode
would just be a safety feature, not a security feature.

But then, how can a user program print output, which requires
privileged use of I/O devices?

And the answer is interrupts.

Perhaps 60 times a second, for example, a timer interrupt will take
place. The interrupt service procedure will be in kernel mode; it will
switch to the next job waiting to use the CPU, and then it will execute
an instruction that branches back to it, as well as reloading the
program status word for that job. So it will execute a 'return from
interrupt' instruction, but instead of returning from the actual
interrupt that really happened, it will use an *old* return vector (so
it stockpiles the current return vector, for return to the actual
interrupted process, when the round-robin comes again).

To print something, the program may branch to a routine in the
operating system; this routine will perform most of the work for
printing in user mode, and then it will execute an instruction that
acts like an interrupt - a supervisor call instruction on a System/360,
for example - to call upon the kernel mode portion of the operating
system to do the part of printing that requires kernel mode.

This instruction doesn't branch to an address chosen by the user.
Instead, it uses a software interrupt vector from a relatively short
list kept in a fixed location that is protected from being written by
most user mode processes. That means that user mode programs can only
call upon the kernel mode part of the operating system to do
specifically-defined and permitted things - at least if the operating
system is written that way. (It is possible to have an operating system
that doesn't bother to strictly enforce security, of course.)

What you are calling user mode and kernel mode may have other names on
other kinds of computers, such as problem state and supervisor state.

John Savard

"Nick Maclaren" < XXXX@XXXXX.COM > wrote

No, that is not how they are implemented, not on the
processors I'm familiar with. However, state save and
vectoring methods are often shared, for efficiency's
(mental and actual) sake.

E.g. ARM software interrupts (SWI), data aborts, and
prefetch aborts all jump via the vector table and do
state-saving, just like both kinds of ARM interrupts
(IRQ and FIQ) do. However, SWI's and aborts do not
generate an interrupt in the process.