views:

433

answers:

4

CPU Switches from User mode to Kernel Mode : What exactly does it do? How does it makes this transition?

EDIT:

Even if it is architecture dependent please provide me with an answer. The architecture is up to you. Tell me for the architecture you know about.

I want to get an idea about what all things will be involved in it.

+4  A: 

That's system dependent, but the usual mechanism is some userland operation causes a software interrupt. That interrupt makes the processor switch modes and jump into kernel code, which then checks what the program was trying to do (system call?) and then does the requested action and jumps back to the user mode code. Other mechanisms besides a software interrupt might cause the transition as well; for instance in a preemptive multitasking system, a timer interrupt might trigger the scheduler to run.

Carl Norum
So, are these two the only situations when CPU goes into Kernel Mode?
claws
@claws, it's completely processor, operating system, and implementation dependent.
Carl Norum
The comment about system calls happening via a interrupt is somewhat dated. Older Linux used to use interrupt 0x80 to switch to kernel mode on a system call. But with newer processors (where new is anything > pentium 2) and linux kernels, there was a shift to using the "fast system call" facility provided via sysenter,sysexit instructions. Check out http://articles.manugarg.com/systemcallinlinux2_6.html
Jasmeet
@Jasmeet, that's still semantically equivalent to a software interrupt, even if it doesn't have the same name in Intel's jargon.
Carl Norum
A: 

In Windows, when you make a systemcall, the library routines call a kernel entrypoint residing in the operating system address space. It in turn takes the CPU into supervisor mode by executing an instruction specific for this purpose, such as sysenter. What it does is essentially setting a bit in the flags register. This enables the OS to use privileged instructions.

Jens Björnhager
+3  A: 

Note: this is mostly relevant to x86 architecture. Here's a somewhat simplified explanation.

The transition is usually caused by one of the following:

  • Fault (e.g. a page fault or some other exception caused by executing an instruction)
  • Interrupt (e.g. a keyboard interrupt or I/O finishing)
  • Trap (e.g. a system call)

What normally happens is that system checks the Interrupt Descriptor Table (IDT). Each exception (interrupt, fault, etc.) has a number associated with it which is used to index into this table.

From this table the CPU can determine the interrupt handler to run.

As part of the transition the following changes (generally) take effect:

  • Switch to Kernel stack
  • EFLAGS are saved
  • Code segment selector and EIP are saved.
  • stack segment selector and stack pointer are saved
  • Start executing the interrupt handler
  • The general purpose registers are saved (handler's job)
  • Segment selectors are changed to Kernel ones (handler's job)

You're now in kernel mode.

Hope that helps :)

Omar Alrubaiyan
A: 

@claws : The three scenarios mentioned by Omar are sufficient and complete and in my opinion not architecture or OS dependent.

anupash
this should be a comment. As its not an answer.
claws
oh sorry .. new to Stackoverflow
anupash