CPU从用户模式切换到内核模式：它到底做了什么？它是如何实现这一转变的？
CPU从用户模式切换到内核模式：它到底做了什么？它是如何实现这一转变的？
编辑：
即使它依赖于架构，也请给我一个答案。架构由您决定。告诉我你所知道的架构。
我想了解其中涉及的所有事情。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
注意：这主要与 x86 架构相关。这是一个稍微简化的解释。
转换通常由以下原因之一引起：
通常发生的情况是该系统检查中断描述符表（IDT）。每个异常（中断、故障等）都有一个与之关联的编号，用于索引该表。
从该表中，CPU 可以确定要运行的中断处理程序。
作为转换的一部分，以下更改（通常）会生效：
您现在处于内核模式。
希望有帮助:)
Note: this is mostly relevant to x86 architecture. Here's a somewhat simplified explanation.
The transition is usually caused by one of the following:
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:
You're now in kernel mode.
Hope that helps :)
这取决于系统，但通常的机制是某些用户态操作导致软件中断。该中断使处理器切换模式并跳转到内核代码，然后内核代码检查程序试图执行的操作（系统调用？），然后执行请求的操作并跳回用户模式代码。除了软件中断之外的其他机制也可能导致转换；例如，在抢占式多任务系统中，计时器中断可能会触发调度程序运行。
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.
我的理解是，段寄存器的两个 LSB 为零的任何程序都将在内核模式下运行，而段寄存器的两个 LSB = 1 的任何程序都将在用户模式下运行。事实上，段寄存器的两个 LSB 定义了特权级别（0 最高到 3 最低），
因此，要使程序在内核模式下运行，您必须将段寄存器设置为 0010 十六进制（我相信）。我不确定如何将程序放置在该内存空间中而不覆盖其他内容 - 换句话说，链接器如何确保这一点？
另外，如果您想从用户模式代码调用内核模式代码，您必须弄清楚如何传递参数 - 它们不使用相同的内存空间，因此无法通过内存引用传递数据。我想你必须在寄存器中传递它。
如果有人能填补以上空白，我将不胜感激。
My understanding is that any program whose segment registers have the two LSBs zero will be running in Kernel mode while any program whose segment registers have the two LSBs = 1 will be running in User Mode. In fact, the two LSBs of the segment rgeisters define the Priviledge Level (0 highest to 3 lowest)
So, to make a prgram run in Kernel mode you have to set up the segment registers to be 0010 hex (I believe). I'm not sure how you can place a program in that memory space without overwriting something else - in other words, how does the linker ensure that?
Also, if you want to call the Kernel mode code from User mode code, you have to figure out how to pass parameters - they are not using the same memory soace, so can't pass data by memory reference. I guess you have to pass it in registers.
If anynody can fill in the gaps in the above, I would be very grateful.
在 Windows 中，当您进行系统调用时，库例程会调用驻留在操作系统地址空间中的内核入口点。反过来，它通过执行专门用于此目的的指令（例如 sysenter）将 CPU 置于管理模式。它的作用本质上是在标志寄存器中设置一个位。这使得操作系统能够使用特权指令。
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.
我想给出基于纯逻辑的答案 -
->任何时候我们都可以将主内存中运行的进程分为两类 - 特权（p）和特权（p）。非特权(np)，
-> p 的示例是 - 操作系统、主管（在现代系统中）
-> p 本身负责运行 np - 它以用户进程（np）作为输入，并通过给予它们控制权来运行它们...
->通过图灵的停止问题证明，没有通用的方法可以知道任何进程何时会做什么（“没有tm可以决定给定的tm是否会在一般情况下打印给定的符号”），因此，p（任何操作系统）永远不会知道当某个 np 肯定会尝试执行 privilegdes 指令时..
->因此，必须有一个硬连线机制，以便每当一条指令被证明具有解码特权时，控制权就会返回到特定内存位置的特定进程，至少系统认为该位置是可信的。
[当我说硬连线时，我的意思是在微体系结构级别，即没有 ISA 不应给出任何明确的指令来进行这种转换（废话！），假设如果有一个，那么该指令本身必须具有特权，并且系统必须提供均匀的更高级别的硬连线方式将控制权转移到 p，或者任何 np 将简单地使用该指令来转换到特权模式。 ]
因此，至少在最核心的转变必须是硬连线的，现在虽然形式上我们仍然可以根据两种情况对转变进行分类 -
->这种转变是恶意完成的 -
->进行转换是为了减少劳动力（从操作系统获得帮助） -
这里操作系统开发人员向语言开发人员提供实现细节。它们可以提供的函数的名称是什么、它们做什么、它们采用什么参数、np 在实现架构特定程序来更改 cpu 模式之前必须做哪些准备工作（cpu 是硬连线的，可以自行完成其余的工作） ）等等。
在调用这些函数（称为系统调用）时，编译器使用实现细节来符合操作系统执行特定工作所需的预先要求，然后进行系统调用的 np 执行更改体系结构的特定方式模式 - 通常是该架构/系统的 ISA 中列出的指令，系统/CPU 将控制权转移给操作系统，如果 np 想要它做任何事情，操作系统会检查它要求的详细信息，如果没有找到有效的详细信息操作系统返回错误消息，如果找到，操作系统将执行该作业，完成作业后，操作系统将控制权返回给 np ....
i want to give the ans based on pure logic -
-> at any time we can categorize the processes running in the main memory in 2 categories - priviledged(p) & non-priviledged(np),
-> egs for p are - OS, supervisor(in modern systems)
-> p itself is responsible for running np - it takes user processes(np) as input, and runs them by giving them the control...
-> by turing's halting problem proof, there's no general way to know when any process will do what ( ' no t.m. can decide whether a given t.m. will ever even print a given symbol in general ' ) , THUS , p (any OS) can NEVER KNOW when a certain np will try to execute a privilegdes instruction for sure..
-> HENCE, THERE HAS TO BE A HARDWIRED MECHANISM so that whenever an instruction turns out to be priviledged on decoding, the control is returned to a particular process at a particular memory location, which atleast the system believes to be trusted.
[ When i say hardwire, i mean in the microarchitecture level, i.e. no ISA shall give any explicit instruction to make such transition(duh!) , suppose if there is one, then that instruction itself must be priviledged and the system must provide an even higher level hardwired way to shift the control to p, OR any np would simply use that instruction to make transition to priviledged mode. ]
So atleast at the very core the transition must be hardwired, now although formally we can still categorize the transition based on 2 scenarios -
-> the transition is done malliciously -
-> the transition is done to reduce labor (get help from the OS) -
here the OS developers provide implementation details to language devs. as what shall be the name of the functions they can provide, what they do, what arguments they take, what preliminaries the np must do before they implement the architecture specific procedure to change cpu mode (cpu is hardwired to do the rest on its own) and so on .
On calling these functions ( called system calls ) the compiler uses the implementation details to conform to the pre-requirements the OS requires to do the specific job, then the np making the system call performs the architecture specific way of the changing the mode - usually an instruction listed in ISA of that architecture/system, the system/cpu shifts the control to OS, the OS checks for the details it asked to be there if an np wants it to do anything, if no valid details found OS returns with error message, if found , OS does the job, on completing the job the OS returns the control to the np ....