注意：这主要与x86架构相关，这里有一个稍微简化的解释。
转换通常由以下原因之一引起：

• 错误（例如，由于执行指令而导致的页面错误或其他异常）
• 中断（例如键盘中断或I/O结束）
• 陷阱（例如系统调用）

通常情况下，系统会检查异常描述符表（IDT）。每个异常（中断、故障等）都有一个与之相关的编号，用于索引到该表中。
从这个表中，CPU可以确定要运行的中断处理程序。
作为过渡的一部分，以下更改（通常）生效：

• 切换到内核堆栈
• 保存EFLAGS
• 保存码段选择器和弹性公网IP。
• 堆栈段选择器和堆栈指针被保存
• 开始执行中断处理程序
• 保存通用寄存器（处理程序的工作）
• 段选择器改为内核选择器（处理程序的工作）

你现在处于内核模式。
希望对你有帮助：）

这与系统有关，但通常的机制是一些用户操作会导致软件中断，该中断会使处理器切换模式并跳转到内核代码，然后内核代码会检查程序试图做什么（系统调用？），然后执行所请求的操作并跳回到用户模式代码。除了软件中断之外，其他机制也可能导致转换;例如，在抢占式多任务系统中，定时器中断可以触发调度器运行。

我的理解是，任何程序的段寄存器有两个LSB零将运行在内核模式，而任何程序的段寄存器有两个LSB = 1将运行在用户模式。事实上，两个LSB的段寄存器定义的特权级别（0最高到3最低）
因此，要使prgram在内核模式下运行，您必须将段寄存器设置为0010十六进制我不知道你怎么能把一个程序放在那个内存空间里而不去复制别的东西--换句话说，链接器是怎么保证的？另外，如果你想从用户模式代码调用内核模式代码，你必须弄清楚如何传递参数-它们不使用相同的内存空间，所以不能通过内存引用传递数据。我猜你必须在寄存器中传递它。
如果有任何人能填补上述空白，我将不胜感激。

在Windows中，当你进行系统调用时，库例程调用驻留在操作系统地址空间中的内核入口点。它反过来通过执行专用于此目的的指令（如 sysenter）将CPU带入管理模式。它所做的实质上是在标志寄存器中设置一个位。这使操作系统能够使用特权指令。

我想给予基于纯逻辑的答案-
->在任何时候，我们都可以将主内存中运行的进程分为两类-privileded（p）和non-privileded（np），
-> egs for p are - OS，supervisor（在现代系统中）
-> p本身负责运行np -它将用户进程（np）作为输入，并通过给予它们控制权来运行它们。
->通过图灵的停机问题证明，没有一般的方法来知道任何进程何时会做什么（“没有t.m.可以决定给定的t.m.是否会打印给定的符号”），因此，p（任何操作系统）永远不会知道某个np何时会尝试执行一个特定的指令。
因此，必须有一个硬件机制，以便每当一条指令在解码时被特权化时，控制权就会返回到特定内存位置的特定进程，至少系统认为该内存位置是可信的。
[当我说硬连线时，我的意思是在微体系结构级别，即没有ISA应该给予任何明确的指令来进行这种转换（duh！），假设如果有一个，那么该指令本身必须是特权的，系统必须提供更高级别的硬连线方式来将控制转移到p，或者任何np将简单地使用该指令来转换到特权模式。
因此，至少在最核心的过渡必须是硬连接的，现在虽然正式我们仍然可以分类的过渡基于2个场景-
->过渡是恶意完成的-

• 上面的例子是人们说的原因-“没有适当的硬件（硬连线）支持，操作系统是一样好没有“，基本上暗示操作系统是高度脆弱的.

->转换是为了减少劳动力（从操作系统获得帮助）-

• 这里，OS开发者向语言开发者提供实现细节，如他们可以提供的函数的名称是什么，他们做什么，他们采用什么参数，NP在实现架构特定过程以改变CPU模式（CPU被硬连线以自己完成其余的）之前必须做什么操作等等。
• 在调用这些函数时（称为系统调用）编译器使用实现细节来符合OS要求做特定工作的先决条件，然后进行系统调用的np执行改变模式的架构特定方式-通常是该架构/系统的伊萨中列出的指令，系统/CPU将控制转移到OS，如果NP希望它做任何事情，则OS检查它要求的细节，如果没有发现有效的细节，则OS返回错误消息，如果找到，则OS执行作业，在完成作业时，OS将控制返回给NP....