Linux内核笔记008 - 中断的概念及硬件支持

爱被打了一巴掌 2022-12-02 13:48 100阅读 0赞

> 本文转自网络文章，内容均为非盈利，版权归原作者所有。  
> 转载此文章仅为个人收藏，分享知识，如有侵权，马上删除。  
> 原文作者：jmpcall  
> 专栏地址：[https://zhuanlan.kanxue.com/user-815036.htm][https_zhuanlan.kanxue.com_user-815036.htm]

## 1. 概念了解 ##

有时候，应用程序开发的经验，很容易使我们的视野，停留在单个进程中，反而阻碍理解。我的方法是，把整个系统看成一个"大程序"，这个程序最开始只有内核部分，随着执行，它又动态加载了一些指令和数据，作为自身的"生长部分"，也就是说，把"进程"理解为整个"大程序"的"生长部分"。这样理解的好处是，会让视野从单个进程中走出来，从而才能看得清整个系统的运行逻辑：

![format_png][]

① 任何时刻，这个"大程序"只有一条指令在被CPU执行。

② 系统启动阶段，从内核的代码开始执行，内核运行过程中，会动态扩展自己的指令和数据，并为"生长部分"分配独立的管理结构（上次从该"生长部分"跳转走的位置等），以及"生长部分"本身独立使用的资源（"虚拟地址-物理地址"映射表等）。

③ 刚通电时，CPU为"实模式"状态，通过执行内核代码，切换到"保护模式"，使得程序中的地址，要经过一次映射，才能得到物理地址，为各个"生长部分"的内存隔离，建立了基础。刚切换到"保护模式"时，CPU可以执行特权指令，并逐步创建了一些进程，由于内核开发人员，无法预测计算机用户，懂不懂自己去控制各种硬件，所以内核封装了大量接口给"生长部分"使用，同时也无法预测用户的程序会不会有bug，所以在跳转到"生长部分"之前，将CPU的特权级别修改为低级别。

这样，疑问就很自然的产生了：

*  某个"生长部分"执行while(1)死循环，为什么仍然可以执行到其它"生长部分"？

CPU硬件层，提供了"时钟中断"功能，内核在启动阶段设置"时钟中断"处理函数并开启"时钟中断"功能，之后每隔一定时间，无论CPU执行到"大程序"的哪个地方，都会被"时钟中断"逻辑，保存CPU当时的执行状态（当时执行的指令位置、特权级别等），然后跳转到"时钟中断"处理函数，进一步再跳转到其它"生长部分"执行。

*  "生长部分"有bug，比如执行"除0"操作，是如何coredump的？

软件中使用的指令集，都是由硬件提供的，而硬件层的设计保证了，当"除法指令"的除数为0时，保存CPU当时的执行状态，跳转到"除0"的异常处理函数执行，和"时钟中断"处理函数一样，各种异常处理函数，也都是由内核实现并在启动阶段设置。

*  "生长部分"如何调用内核接口？

由于内核开发人员，只能掌控自己实现的代码，无法预测用户的代码，所以，整个"大程序"在往"生长部分"跳转的同时，一定会降低CPU权限，跳转回内核代码的同时，也必须提升CPU权限。有一种方法是，在软件层保证，每个中断处理函数，都在特权指令之前，执行提升CPU权限的指令，但这样，就增加了内核实现的负担，同时也会让中断处理函数的代码看起来很臃肿。

所以，硬件层保证了这一点，回忆一下[Linux内核笔记001][Linux_001]介绍过的段描述符：

![format_png 1][]![format_png 1][]

如果type字段的二进程值为100/101/110/111，硬件层就会按照"门"的含义解释：

![format_png 2][]

![format_png 3][]

利用"门"，应用程序中执行一条指令（int/call/jmp），就可以同时完成"向内核代码跳转"和"提升CPU权限"两个动作，具体过程稍后详细学习，这里先根据上述内容，做个小小的展开，这样稍后深入到细节分析时，就不会思维混乱了：

① 内核代码，一部分在刚开机时执行，没有进程上下文，一部分在创建进程后，被进程"调用"执行，有进程上下文；

② 用户态是通过"门"，切换到内核态，根据触发条件，分为中断、异常、陷阱。时钟中断，跟当时的进程上下文无关，CPU异常处理函数内部，可能又会出现缺页等异常，或者发生时钟中断，就会出现"中断嵌套"的情况。

![format_png 4][]

## 2. X86 CPU对中断的硬件支持 ##

*  任务门

80386提供的4种"门"，结构图都可以从上述内容看到，它们有个共同的特点，就是对应段描述符"B15-B0"的位置，都被CPU硬件层设计解释为段选择子，也就是说，通过"门"，最终得到的仍然是段描述符，只是多走了一道而已。相比于其它三种"门"，任务门的段描述符，指向长度固定为104的段，并且整个段被CPU硬件层设计解释为TSS结构，也正是用于得到段的首地址，就能得到TSS结构的地址，所以对应其它三种"门"中表示位移的位置，空闲不用。

![format_png 5][]

① 什么是TSS？

由于CPU硬件设计阶段，无法完全预料内核会放弃使用哪些硬件特征，或者由于历史原因和对兼容性的考虑，会存在一些软件层不愿意使用，但又无法关闭的功能，对于这样的功能，软件层一般只是"假装"使用， 即逻辑上并没有使用，纯粹保证硬件内部执行不出错而已。比如：80386寻址过程中，段式寻址逻辑是必然要执行的，同时段式寻址的设计意图决定了，各个进程的虚拟空间，必须用独立的LDT管理，内核也必须用GDT管理各个LDT所在的段。所以，尽管Linux内核只想用"页"记录进程的虚拟空间使用情况，但仍然要为各个进程安排一个LDT，并在GDT设置一个全局描述符指定它，只不过所有进程都使用同一个LDT，并且LDT中始终只有一个局部描述符，指向0地址开始的整个4G虚拟空间。

本篇笔记开始部分，将整个系统看作一个"大程序"，当时也一步步分析了，"生长部分"需要有资源记录本身的"虚拟地址-物理地址"映射关系，LDT正是用于这个目的，另外还需要其它管理信息，比如，上次从该"生长部分"跳转走时的位置、各个寄存器的值等。为此，CPU硬件层，还要求内核为每个进程，设置一个TSS结构（定义如下），每个进程的TSS要独占一个段，并在GDT中设置一个全局描述符。

struct tss_struct {
        unsigned short back_link,__blh;
        unsigned long  esp0;
        unsigned short ss0,__ss0h;
        unsigned long  esp1;
        unsigned short ss1,__ss1h;
        unsigned long  esp2;
        unsigned short ss2,__ss2h;
        unsigned long  __cr3;
        unsigned long  eip;
        unsigned long  eflags;
        unsigned long  eax,ecx,edx,ebx;
        unsigned long  esp;
        unsigned long  ebp;
        unsigned long  esi;
        unsigned long  edi;
        unsigned short es, __esh;
        unsigned short cs, __csh;
        unsigned short ss, __ssh;
        unsigned short ds, __dsh;
        unsigned short fs, __fsh;
        unsigned short gs, __gsh;
        unsigned short ldt, __ldth;
        unsigned short trace, bitmap;
        unsigned long  io_bitmap[IO_BITMAP_SIZE+1];
        /*
         * pads the TSS to be cacheline-aligned (size is 0x100)
         */
        unsigned long __cacheline_filler[5];
    };

② TSS是不是只能通过任务门访问？

80386任务门的本质，就是硬件层设计，将所含的段选择子，解释为TSS段描述符：执行int/call/jmp指令时，如果在指令寻址过程中，遇到任务门，CPU就会将当前的状态保存到当前进程的TSS结构（TR寄存器始终指向当前进程的TSS），并让TR寄存器指向新的TSS，从而在硬件层完成进程切换。不过，等到学完第四章"进程与进程调度"，就会发现，Linux内核并不使用任务门进行进程切换，那为什么从Linux内核中，还是能看到TSS相关的代码呢？那是由于，要从"生长部分"主动或被动跳转到内核代码，根据存储在内核空间的进程管理信息，才可以进行进程切换，这个过程会发生CPU权限的变化，而CPU在进入新的运行级别时，会自动从当前进程的TSS中装入相应运行级别的SS和ESP，所以Linux内核仍然要为每个进程设置TSS，并且要正确设置esp0、ss0成员的值，保证切换到内核态时，CPU内部执行不出错。

#define INIT_TSS  {                      \
        0,0, /* back_link, __blh */             \
        sizeof(init_stack) + (long) &init_stack, /* esp0 */   \
        __KERNEL_DS, 0, /* ss0 */               \
        0,0,0,0,0,0, /* stack1, stack2 */           \
        0, /* cr3 */                     \
        0,0, /* eip,eflags */                    \
        0,0,0,0, /* eax,ecx,edx,ebx */               \
        0,0,0,0, /* esp,ebp,esi,edi */               \
        0,0,0,0,0,0, /* es,cs,ss */              \
        0,0,0,0,0,0, /* ds,fs,gs */              \
        __LDT(0),0, /* ldt */                    \
        0, INVALID_IO_BITMAP_OFFSET, /* tace, bitmap */        \
        {~0, } /* ioperm */                 \
    }

*  中断门、陷阱门、调用门

① 和任务门相比，中断门/陷阱门/调用门最终指向的都是某个代码段，并且都要指定对应的执行函数，在整个代码段的多少偏移处；

② 中断门和陷阱门相比，进入中断门后，CPU会将EFLAGS寄存器中IF标志位清0，即不再响应新的中断，可以用于防止中断嵌套，否则如果时钟中断处理函数执行时间，大于时钟中断产生间隔，就会一直执行时钟中断函数；

③ 80386的各种"门"，是为不同的使用场合设计的，权限检查过程各不相同且复杂（"门"本身有DPL，"门"所指段描述符也有DPL），但Linux内核不使用任务门（主要考虑性能），也几乎不使用调用门（简单就是美）；

④ 进入中断处理函数时，CPU要将当前的EFLAGS寄存器、CS:EIP内容，压入栈中，如果是由异常引起的，还要压入一个错误码，如果CPU运行级别改变，要先根据TSS切换到新级别对应的栈，并且先将切换前的CS:EIP压入栈中（下一篇笔记，就会看到这些压栈操作的意义）；

![format_png 6][]

3. 中断向量表IDT的初始化

硬件设计了GDT/LDT寄存器，指向段描述符表，同样，也设计了IDTR寄存器，指向中断向量表（"门描述符"表）。

① INT指令的参数，即为IDT的索引；

② IDT前20个中断向量，完全由CPU硬件层使用，必须按照CPU的硬件规范设置，比如缺页异常时，CPU会自动穿过14号门，如果内核启动阶段，在14号向量设置的门，不能进入缺页异常处理函数，系统就会运行出错。

![format_png 7][]

③ i386的系统结构，支持256个中断向量，软件层从0x20号向量开始使用，共224个，其中80号向量用于系统调用，所以才可以通过"INT 80"，从用户态切换到内核态。

*  start\_kernel()调用trap\_init()、init\_IRQ()分别初始化硬件层、软件层使用的部分

*  trap\_init()函数分析

不管设置哪种门，最终都调用了\_set\_gate()，它是个宏函数：

![format_png 8][]

[Linux内核笔记003][Linux_003]专门学习过AT&T格式汇编，以及它嵌入在C语言中的形式，这个宏函数不难分析：

① 输入部，将3,edx,\_\_d1初始化为addr，将2,eax,\_\_d0初始化为\_\_KERNEL\_CS<<16；

![format_png 9][]

② "movw %%dx,%%ax"：设置AX为DX的值，即addr低16位；

③ "movw %4,%%dx"：设置DX为0x8000+(dpl<<13)+(type<<8))；

![format_png 10][]

④ "movl %%eax,%0"

⑤ "movl %%edx,%1"

以上将"门描述符"的高低32位内容，构造到了EDX、DAX寄存器中，最后两条指令将"门描述符"写入gate\_addr指向的内存中。

## 4. 中断请求队列的初始化 ##

软件层从0x20号向量开始使用，80号向量用于系统调用，还剩223个可以使用，Linux内核的使用方式为：

启动时，为各个门设置处理函数"IRQ0xXX\_interrupt->common\_interrupt->do\_IRQ()"，其中IRQ0xXX\_interrupt、common\_interrupt的代码中，没有RET指令，并且不是用CALL指令跳转，而是用JMP指令跳转的，可以把三者看作一个整体"do\_IRQ\_XX()"，不过，"do\_IRQ\_XX()"只是执行最终处理函数的"通道"，最终处理函数，是挂在irq\_desc\[0xXX\].action链表中的，由"do\_IRQ\_XX()"遍历间接执行。

![format_png 11][]

这样，通过一个中断向量，就可以执行多个不同的函数。比如，两个不同的驱动中，都希望响应某个相同的中断，它们的处理函数，就可以共用同一个中断向量。

另外，外设与中断控制器，位置关系大概如下：

![format_png 12][]

PCI驱动显然知道，各个外设插槽与中断控制器引脚的对应关系，相应的，外设驱动将中断信号发送到CPU，对应的IRQ号为多少，也是可以获取的，也就可以，将中断控制器提供的一套引脚操作函数，记录到相应的irq\_desc\[0xXX\].handler，供外设驱动从中断控制器层，对各个"中断通道"进程控制。

![format_png 13][]![format_png 13][]

介绍到这里，init\_IRQ()函数就不难分析了：

init_IRQ()
     |- init_ISA_irqs()
     |   |  // 初始化i8259A中断控制器
     |   |- init_8259A()
     |   |- for (0->15)
     |   |   |- irq_desc[i].handler = &i8259A_irq_type
     | /*
     |  * interrupt函数指针数组：
     |  * void (*interrupt[NR_IRQS])(void) = {
     |  *   IRQLIST_16(0x0),
     |  * };   |
     |  *      |- IRQ(0x0,0)
     |  *      |   |- IRQ0x00_interrupt
     |  *      |- ..
     |  *      |- IRQ(0x0,f)
     |  *          |- IRQ0x0f_interrupt
     | */
     | /*
     |  * IRQ0xXX_interrupt()函数定义：
     |  * BUILD_16_IRQS(0x0)
     |  *  |- BI(0x0,0)
     |  *  |   |- BUILD_IRQ(0x00)
     |  *  |   |   |- IRQ_NAME(0x00)
     |  *  |   |       |- IRQ_NAME2(IRQ0x00)
     |  *  |   |           |- IRQ0x00_interrupt(void)
     |  *  |   |- asmlinkage void IRQ0x00_interrupt(void)
     |  *  |   |  __asm__( \
     |  *  |   |    ".align 0"
     |  *  |   |    "IRQ0x00_interrupt:"
     |  *  |   |    "pushl $0x00-256"
     |  *  |   |    "jmp common_interrupt");
     |  *  |- ..
     |  *  |- BI(0x0,f)
     |  *      |- asmlinkage void IRQ0x0f_interrupt(void)
     | */
     |  // 设置20~35号中断向量对应的门，处理函数分别为IRQ0x00_interrupt(), .., IRQ0x0f_interrupt()
     |- for (0->15)
     |   |- set_intr_gate()

[https_zhuanlan.kanxue.com_user-815036.htm]: https://zhuanlan.kanxue.com/user-815036.htm
[format_png]: /images/20221123/58c33a9c02134181b7abbf9d648ee5bb.png
[Linux_001]: https://blog.csdn.net/u013469753/article/details/108316191
[format_png 1]: /images/20221123/19acc59f7fa04d7aad959b4fa5cc0eb0.png
[format_png 2]: /images/20221123/76e15dd3fac14b15b6d852cd3a339a81.png
[format_png 3]: /images/20221123/b020e70485dc468c99587aa9c3c355d9.png
[format_png 4]: /images/20221123/32a9eafc73134f50b3ccbf9d5bf20c41.png
[format_png 5]: /images/20221123/94407f56731c4eedb5ec7a449f2c9402.png
[format_png 6]: /images/20221123/65b08a14ad9c4144b12c22349c5ab539.png
[format_png 7]: /images/20221123/195193b2e1e2441b8c30f3c87d3ae0a8.png
[format_png 8]: /images/20221123/7475af2083f24ac4badf5d2cf75909ec.png
[Linux_003]: https://blog.csdn.net/u013469753/article/details/108316708
[format_png 9]: /images/20221123/319a8a19a03e480ea85bb452c16a7b7e.png
[format_png 10]: /images/20221123/8fb55272fbbe4f5996260e99bbd58d91.png
[format_png 11]: /images/20221123/cc3743f99c2641df96da600eef104c0a.png
[format_png 12]: /images/20221123/cda74a66204e468bba4b760628e7c966.png
[format_png 13]: /images/20221123/d30d4280863d4ae581529919c8997407.png