请教ULK3中关于中断的两个问题

_nosay

回复 1# ymc4444


以下是我的个人理解，除了回答你的问题，也有自己额外的总结，希望你能把分给我：
问题一：任务门本来就是硬件为方便软件进行进程(任务)切换设计的。
CPU上有个TR寄存器，它期望软件在内存中为每个进程安排各自的TSS段以及任务门，穿过任务门时，硬件负责将该任务门中“TSS段寄存器值”赋给TR寄存器，从而达到进程切换的目的。
只不过Linux切换进程（任务），并不使用任务门，因为从层级关系来看，硬件比软件更底层，它没有充足的信息来舍弃不需要的操作，导致通过任务门切换进程时，硬件上会执行一堆臃肿的操作，效率不行。

新问题：那么Linux是怎么切换进程的呢？
进程的切换，本质就是硬件状态的改变：
进程A运行时，SS+ESP寄存器指向进程A的堆栈，CS+EIP寄存器指向进程A的指令，CR3寄存器指向进程A的目录表。。
切换到进程B，无非是让SS+ESP寄存器指向进程B的堆栈，CS+EIP寄存器指向进程B的指令，CR3寄存器指向进程B的目录表。。
而修改SS、ESP、CS、EIP、CR3等等这些操作，硬件都向软件提供对应的指令了，所以穿过任务门时硬件做的操作，软件当然也可以自己做，从而在软件层面也可以设计进程切换的过程，并没有什么奇怪。

不使用任务门，不代表Linux就可以没有TSS这个东西了，因为不只是穿过任务门时才需要它。比如用户态执行系统调用穿过陷阱门往内核态切换时，就要根据TR寄存器找到“当前进程的TSS段”，根据里面的SS0、ESP0成员值，修改SS、ESP寄存器，切换到该进程的内核堆栈，以及将当前进程的EFLAGS寄存器压入内核堆栈。

简单粗暴的说：硬件提供给“懒程序”一种切换进程的方式，就是通过int(或jmp、call)穿过其它进程的任务门即可，硬件会根据任务门中的“TSS段寄存器”修改TR寄存器，将整个TSS段读到CPU的高级缓存并使用；Linux切换进程时，并不修改TR寄存器，因为它只需要修改TSS段中的部分必要内容，所以所有进程有一个“公共TSS”，CPU的时间片轮到自己时，要根据自己在GDT中的TSS段描述符，找到自己的TSS内容，并修改“公共TSS”，这样CPU只需要往高级缓存读缓存失效的那一部分。

你的反问+“信号”的躺枪，表示你还需要好好体会一下。
信号和进程切换都是在内核态往用户态切换时，判断要不要做，它们的区别是“进程切换”到用户态后，就留在用户态了，直到下一次中断（或异常、陷阱），而“信号”切换用户态执行完信号处理函数后，要马上回到内核态，因为还要执行其它关心该信号的进程的的信号处理函数呢。

我们平时写信号处理函数，也没有加int保证返回内核，那么信号处理函数执行完是如何“自觉”回到内核态的呢？
因为内核在切换到用户态之前，在用户态堆栈“返回地址”的位置（就是平时我们写funa()调用funb()，编译器为funb()执行完，取返回funa()的地址的位置），安排了一个指向返回内核态的指令的地址。

问题二：“用户态<->内核态切换”、“进程切换”，两种切换不要搞混淆。
硬件自己引起的“中断”（可以理解为不是程序里的int指令引起的吧），比如时钟中断、缺页/除0异常等，是没有你说的这个检查的，因为硬件本身的设计会对这些情况进行保证，而进程自己通过int指令企图“中断”，才会跟当前进程有关系，作为比软件底层的硬件，硬件工程师无法确保软件不会在不合理的情形下int，所以才要根据进程的信息进行检查。

新问题：app程序通过int切换到内核态，让进程从3级变成0级，权利提高了，是不是就可以为所欲为了？
不可以。app拥有权利的时候，同时也必须按照内核工程师写的代码执行，即已沦为傀儡，除非能找到内核的漏洞。

nswcfd

task gate的行为是CPU规定的，跟OS层面的“任务/进程”没有关系，更谈不上调度（OS层面的概念）。

问题二描述的也是CPU的行为，跟“任务/进程”没有关系。
估计是翻译的原因吧，什么时候“中断处理程序”是个“程序”啊

今天不吃面

中断有两种触发方式，一种就是硬件异步产生的，常规的中断，比如你按了一个键，这种的是不检查特权的，
还有一种是汇编指令int，软件模拟中断，这种的是要检查的

nswcfd

笔误，学习了。