x86, how does a process switch from user mode to kernel mode
|
From: rohit.nadig@gmail.com on 4 Oct 2006 20:08 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
From: nedbrek@yahoo.com on 4 Oct 2006 21:55 Hello, rohit.nadig(a)gmail.com wrote: > I have a naive question about how the context switch between user mode > and kernel mode happens in a live processor. [snip] > 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? [snip] > Thank you, > Rohit 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.intel.com/design/pentium4/manuals/253666.htm which is for the Pentium 4. The relevant manuals are volume 3 (system programming guide). Hope that helps! Ned
From: Nick Maclaren on 5 Oct 2006 05:00 In article <1160013304.957789.4810(a)m7g2000cwm.googlegroups.com>, "nedbrek(a)yahoo.com" <nedbrek(a)yahoo.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.
From: michael.spath on 5 Oct 2006 15:14 Nick Maclaren wrote: > 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. Well, OS use what processors provide, and it's not like x86 provides dozens of methods for ring transition. > 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. MS
From: Nick Maclaren on 5 Oct 2006 15:25
In article <1160075672.996099.214810(a)k70g2000cwa.googlegroups.com>, michael.spath(a)gmail.com writes: |> Nick Maclaren wrote: |> |> 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. |