linux进程切换与intel的tss任务切换

本文作者主要想聊聊linux进程切换是如何与intel的tss配合工作的。
最近工作中遇到一些问题，引发了我的一些思考，我在看到进程切换做寄存器上下文保存和切换时，涉及到了tss的操作，而我是一头雾水，进而引发了强烈的好奇心，想要探究一下到底是怎么回事。

经过网络检索以及内核代码的学习，总算有一些眉目了。

首先需要搞懂什么是tss? 它全称叫做task status segment。简单来讲，可以把它理解为是一块内存段，用来保存任务的寄存器信息的，主要用于任务切换时做寄存器的上下文切换，这块内存具有固定的格式，只有这样硬件才能识别处理。它是intel提供的硬件能力，什么意思，就是说寄存器的保存和读取由硬件来做，不需要软件参与。当然也不能完全没有软件，软件需要做的就是配置好tss。intel设计该功能的初衷就是想要简化任务切换的过程，该功能的预期是每个任务都拥有独立的tss内存，那么想要做任务切换时，只需要软件把指定任务的tss selector设置到tr寄存器，那么硬件就会执行相应的寄存器上下文的切换。

linux作为一款操作系统软件，它需要实现任务切换，它并没有遵循intel的建议为每个任务创建独立的tss。实际上linux压根就没想使用这套机制。为什么？主要是采用mov指令更加灵活，还可以判断命令的合法性，另外采用硬件tss操作上下文切换和普通的mov实现上下文切换，两者性能差不多，因此linux选择了自己软件实现上下文切换。

linux怎么做的呢？因为调度是以进程为单位，因此进程的上下文依然还是需要做保存和恢复的，只不过直接使用mov指令把各个寄存器保存到一块内存区域，并且该区域可以通过task struct结构体找到。这种实现既简单又通用。

虽然linux使用的是内核栈保存上下文寄存器，但是搜索内核代码，依然看到了很多tss相关的操作，那这又是怎么一回事呢？实际上内核并未完全抛弃tss，该特性在某些场景下还是很适用的，主要体现在以下场景:
1.当用户态经过系统调用进入内核态时，需要做用户态栈和内核栈的切换
2.当用户态执行in和out这种io操作时，利用tss做一些权限检查
那么下面来看linux是如何借助tss实现这两个功能的。首先定义了tss并不是每个进程都有一个，而是每个cpu都拥有一个tss结构，该结构只记录当前正在运行进程的内核栈，每次做进程切换时，都需要更新它为最新要运行的进程对应的内核栈。实际上相当于是对应着current进程，那么设置了以后，后续当发生用户态到内核态动作时就会触发相应的上下文切换，找到该进程的内核栈。对于第二个功能也是同理，类似的设计。

下面具体来看下tss在系统调用中的作用：
首先我们知道x86可以借助int 0x80中断来实现系统调用，一般处理器中断向量表地址是固定的，当发生中断后，CPU会自动跳转到指定的地址去运行，X86上硬件是跳转这个地址以及利用TSS切换堆栈的过程如下，当触发了int 0x80系统调用之后，硬件会做如下的操作：
1.在调用 int 0x80 后，硬件根据向量号在 IDT 中找到对应的表项，即中断描述符，进行特权级检查，发现 DPL = CPL = 3 ，允许调用。
2.然后硬件将切换到内核栈 (tss.ss0 : tss.esp0)，按照intel的最初设计，每个tss结构都表示一个进程，那么进程可能处于不同的ring级别，因此每个结构都有保存ss0/ss1/ss2以及esp0/esp1/esp2，linux在实现上只是用到了ss0、esp0，也就是只保存进程内核栈地址。也就在进程从用户态切换到内核态ring0时自动做栈的切换。
3.接着根据中断描述符的 segment selector 在 GDT / LDT 中找到对应的段描述符，从段描述符拿到段的基址，加载到 cs 。将 offset 加载到 eip。
4.最后硬件将 ss / sp / eflags / cs / ip / error code 依次压到内核栈。

因此我们需要在内核态维护一个tss结构体，并且是一个per-cpu的结构体，并且始终被设置为当前进程的内核栈地址。

在系统调用返回时：
返回时，iret 将先前压栈的 ss / sp / eflags / cs / ip 弹出，恢复用户态调用时的寄存器上下文。

以上就大致就是linux内核与tss之间的关系，我自己的理解，如有错误，欢迎指正，相互交流。