终止处置流程

正如咱们前文讲到的，终止处置在8086时代就曾经引入PC。咱们就从这个远古的鼻祖说起。

1。终止向量表

你有没有猎奇过，0内存地址开局放了些什么物品呢？毕竟是最开局就要用的物品，肯定十分关键！没错，那里就是终止向量表的家。在8086开局，终止向量表就占据这里，甚至在咱们最新时尚的酷睿x代，它们还在这里。想不想看看这个固执的家伙的样子？写个繁难的程序：

de>long*p=(long*)0;printf(%x,*p);

运转下看看。不出所料你的程序将发生一个意外，造成被强迫封锁。还记得咱们前面讲过地址转换，这个0地址是虚构地址而不是物理地址，在包全形式下0的虚构地址访问会发生一个意外，你是访问不到物理0地址的。咱们在内核形式经常使用一些技巧或许咱们进入实形式，咱们能力看到它们。每个终止向量（vector）占据4个字节，Intel定义了256个向量，共用去1KB的内存空间。每个向量浮夸无华，就是一个地址，指向该终止（INT）处置函数的入口，这也是它起名vector的要素。整个终止向量表就是一个大函数指针表，一个终止出现，CPU配件就来这里查表，跳到相应地址就行了，好繁难！实践状况稍微复杂点，CPU还要包全现场，将以后环境保管起来（一些寄存器和前往地址等压栈），以便处置完后前往现场继续口头。不过相关于咱们接上去的包全形式的终止处置繁难很多。没错，这个史前遗址只在实形式施展作用，咱们只草草看看它的样子就行了：

这里关键是意外处置.

配件终止向量一区。和咱们上文的8259衔接两相对照一下：

没错，这里就是主8259的IRQ的终止向量区。接上去就是BIOS保管区，作为引见BIOS的专区，这里肯定看一下：

PC传统LegacyBIOS的服务例程都在这里。看到它们不胜唏嘘，曾经INT10H打字和INT13H读写磁盘的美（YUAN）好（SHI）日子又浮如今眼前。。。不好，这是个泄露年龄的话题，前面咱们就不讲了，下课。

开个玩笑，不过终止向量表当天也只在UEFIBIOS为了兼容传统OS启动的CSM模块中起作用，咱们大抵了解一下其中的原理即可。

2.终止形容符

在PC进入包全形式，一个复杂但有很多妙处的机制替代了终止向量表，它就是终止形容符表（IDT，interruptDescriptorTable）。IDT将每个终止或许意外与它的服务例程衔接起来。IDT不再固定放在某个位置，而是可以放在IDTR寄存器指向的恣意内存(说是恣意，也不能太随性，有些小要求，如8字节对齐等)，IDT的表项也从4个字节裁减到8个字节，大小也可以不满256，IDTR也指出了它的最大限度。如图：

IDT除了和终止向量一样指向一个例程地址之外，还包括其余一些消息：

其中的DPL（形容符特权级）与CS寄存器的CPL成功特权级的审核，可以防止低特权级的代码经过软件终止方式提权。它的运作方式和终止向量表相似，更多的是安保审核和或许的口头环境切换（例如ring3->ring0）。

3.终止和意外

ARM体系终止和意外是独自处置的，IRQ终止只是意外列表里的一项而已。X86终止和意外处置却混杂在一同，经常使用同一套机制，看似比拟凌乱。其实意外往往是处置器外部出现的，是同步的；而终止却是外部事情，是异步的。而它们的散布也是不同的，0到31号向量保管给意外，而更高的则往往是配件终止和软件终止。意外分为三种：失误，圈套和停止。这三种类型CPU对它们有不同的处置准则：失误往往是可以复原的，失误修正后再口头刚才的失误就不会出疑问了，改了就是好同志嘛！例如罕用于内存治理的缺页意外，OS经常把内存换出到硬盘，它会在页表上动些手脚，CPU再次访问这块内存会出现意外，OS页面失误意外例程捕捉到后连忙把内存换回来，而后前往原处口头，就像没事出现一样。圈套是留给软件挖坑的，CPU宿愿软件自己挖的坑自己能填上，它可以装作没看见，从下条继续。典型的例子是INT3，咱们的简直一切调试工具（VS，windbg，甚至UEFI的sourceleveldebugger）都用它参与软件断点。停止就重大了，象征着出现配件失误了，它往往能形成Windows蓝屏，linuxpanic等。意外一览表如下：

20到31被预留未来经常使用。配件终止往往就从32开局。

4.终止优先级

PIC形式IRQ数目越高攀象征着优先级越高。而在APIC形式下，IOAPIC衔接的24个IRQ是平权的，先后并不关乎优先级高下。选择终止优先级的是它对应的终止向量的大小，X86体系有256个vector，终止优先级的计算公式是：

优先级=vectornum/16

即每16个终止一组，共享一个优先级，共16个。由于32以下vector被意外和保管占据，2到15是终止的优先级。数字越大越高优先级。终止优先级的控制是靠LAPIC的TPR（TaskPriorityRegister，义务优先级寄存器）来控制的，它的结构如下：

TR只要4位标识可以接受的终止优先级，即16个。CPU内核只处置优先级比TR大的终止，也象征着TR每提高一个数字，就有16个终止被遮盖！看来咱们的终止要想被赶快处置，肯定占个好位置。那么是不是IRQ数目越大，vector就越大呢？这是谁来选择的呢？这事可不由BIOS做主，OS是设置vector的客人。而不同的OS的处置也不近相反，咱们详细看一下。

终止处置通常

Windows、Linux和BIOS在处置终止上有很多区别。咱们从几个方面浮光剪影了解一二。

1.终止向量设置

PIC如何设置终止向量曾经过期，咱们就不提了。这里只引见APIC形式，假设你还记得上节关于IOAPIC的内容，其中最关键的PRT表，它由24个RTE（RedirectionTableEntry）项组成，每一项对应一个IRQ引脚。它的内容除了上节引见过的DestinationField之外，最低8位是该IRQ对应的vector，可以示意256个vector。OS依据自己的战略，为IRQ调配不同的vector。

Windows的HAL在设置vector时是依据系统枚举配件时挨个设置的，由于先枚举的设施其IRQ的大小不确定，所以优先级并无肯定之规。从vector不能推导IRQ，IRQ也不能推导vector，可以说全凭运气。为配件IRQ调配的vector往往从0x31开局调配，应该是为了配合Windows的IRQL概念。大家可以在windbg里输入命令

检查一下自己机器的vector调配状况。这个IRQL比拟让人混杂，实践上它并不是个配件概念，和终止优先级并不同，它是微软定义的一套软件优先级打算。Windows用0到31来示意优先级，数值越大，优先级越高。如下图：

其中DPC/Dispatch是个分水岭，运转在这个优先级的线程不会被其余线程抢占。其上3到26是为了中心配件保管的。最高的31显得很矮小上，谁的位置这么高？你肯定见过它，它就是在Windows蓝屏时的IRQL。HAL会把IRQL翻译到不同的配件平台上，它和X86的终止优先级不是一个概念。

Linux没有IRQL的概念，他的vector就从0x20(32)开局调配，然而由于0x80(128)由于历史要素，被保管做系统调用（后改用sysenter指令，但为了兼容，还是保管），整个空间被一份为二。前面到0xee(238)为止。由于vector的大小相关到优先级，调配的时刻为了保障对各个IOAPIC偏心，调配的时刻在各个IOAPIC间轮番调配。大家可以在shell里输入以下命令检查一下终止向量的调配状况：

cat/proc/interrupts

2.IRQ在多处置器的散发

还有个疑问十分关键。某个vector由哪个CPU内核担任处置呢？Linux为了偏心起见，并不会对BSP（bootstrapprocessor）另眼看待，一切内核一视同仁。Linux经过填写IOAPIC的RTE中的Deliverymode选用最低优先级战略，让TRP都被初始化做固定值，因此IRQ信号就可以偏心的在CPU之间散发。觉得很专制有没有？（分分钟被Linus的专制作风打脸）。有时为了提升性能，咱们可以经过Linux的IRQ亲缘性来让特定内核为咱们服务。咱们可以经过命令

cat/proc/irq/xx/smp_affinity

检查xxIRQ由谁处置，假设是f的话代表是缺省战略，即大家都可以处置。咱们可以经过上方命令调配个专有内核处置

echo2>/proc/irq/xx/smp_affinity

让APICID为2的内核处置。或许经过一些Irqbalance相似的工具来帮咱们性能。

3.UEFI固件中的终止

UEFI固件内核中对意外和终止都有处置，还蕴含很多经常使用IPI调度内核的源程序，程序短小精干，包括少量注释。感兴味的同窗可以经过它学习终止处置和CPU内核调度。UEFI对终止的初始化和经常使用都在CPU的开发包里:

tianocore/edk2

有几个中央值得留意，咱们来逐一看看。

意外

UEFI内核查IDT的初始化程序在UefiCpuPkg的Library/CpuExceptionHandlerLib下。内核为一切的的终止和意外都调配了一致的入口CommonExceptionHandler。它对任何终止和意外没有任何不凡处置，假设没有人对该终止或意外做处置就会dump一些如今的CPU形态如APICID,意外类型等，而后调用CpuDeadLoop堕入死循环，这也是UEFI工程师经常出现的画面。UEFI驱动可以在自己关心的意外中参与自己的处置函数，如允许经过串口和USB源程序级调试UEFI程序的SourceLevelDebugger就是个典型的例子，它Hook住了很多意外，用于调试和捕捉失误，它在：

tianocore/edk2

终止

UEFI的CSM模块还兼容以前BIOS经常使用的INTx软终止方式调用BIOS服务。随着UEFI的宽泛推行和传统OS的慢慢淘汰，CSM也江河日下，有些仅仅面向最新OS的名目都不含CSM的允许，所以关于它的内容这里略过。在包全形式下，UEFI内核仅仅对时钟终止启动了处置，并经过TimerArchitecturalProtocol放开进去供一切UEFI程序调用。兴许你会猎奇，那么多种USB设施和网卡等等的UEFI驱动难道不须要终止处置？是的，他们的终止在UEFI阶段都没有开启，他们的驱动经过Timer加Polling的方式来处置。举个例子，咱们在UEFIShell下拔出键盘，它能立刻起作用不是如在OS中USB控制器发生了终止。而是USB驱动注册了个Timer，过一会就Poll一下看看有没有新设施拔出。就是这个Timer发现了新拔出的键盘的。

这种仅仅依托Timer的做法在OS阶段是行不通的，会带来重大的效劳和功耗疑问。然而在Boot阶段却疑问不大，而且这样做保障了UEFI内核的繁复性。理想上，UEFI并不由止驱动自己开启终止，但开启终止须要处置的终止共享、IOAPIC设置等等疑问须要驱动自己处置，UEFI并不提供允许。

内核可以经过写自己LAPIC的ICR（InterruptCommandRegister）收回IPI（(Inter-ProcessorInterrupt）调度别的内核成功义务，这也是义务调度的基本方法。理想上，由于APICID的不延续性，咱们正是经过发送IPI的方法来统计内核的数量。BSP在启动时须要统计系统中可用的内核时，发送广播IPI，让大家都来报道，BSP开局点数，1，2，3。。。并逐一记载在案。在启动OS前，经过ACPItable通知OS有多少个内核。OS不应该自己统计内核数目，理想上固件可以经过瞒报内核的方式将局部内核挪作他用，但谁会这么做呢？

如何动员IPI在CPUpackage里有少量实例和库，大家可以参考。

其余

一些容易混杂的名词这里要特意说明一下

x:来源于PIC，指终止引脚，后在APIC时代沿用，泛指终止号。

x/INTx:X是终止向量，如前文所说IRQ不等于INT和vector.

：GlobalSystemInterrupt，是ACPIspec规则的全局终止表。它为多IOAPIC状况下确定了系统惟一的一个终止号。例如IOAPIC1有24个IRQ，IOAPIC2也有24个IRQ，则IOAPIC2的GSI是从24开局，GSI=24+IRQ（IOAPIC2）。

：SystemControlInterrupt，系统控制终止，是ACPI定义的，公用于ACPI电源治理的一个IRQ。它在Intel平台上经常与南桥的电源治理模块一同，当外部EC等出现Event后会引发SCI。Windows的SCIISR程序就是驰名的acpi.sys。acpi.sys在收到SCI后会审核GPE形态寄存器以确定是谁引发的event，而后依照ACPIspec要求调用相应Method。概略请参照ACPIspec。可以以为SCI是ACPI定义的一切电源治理事情的总入口，它对应的IRQ在普通状况下是不能修正的。SCI是如何报告和繁难的GPEmethod咱们在下一篇中会详细引见。

结语

说了这么多，假设咱们从配件和软件方面，梳理整个终止设置和处置的链条，会发现还有个过程没有处置。那就设施的IRQ是谁来选择的？是配件hardwired?还是软件可以性能？OS是如何知道这些消息的呢？OS又是怎样知道IOAPIC的数目和位置的呢？这些都是UEFI固件须要处置的疑问，咱们在下一篇文章中会详细说明。在此之前，如以往一样，有几个思索疑问可以让大家加深对终止和UEFI的了解：

1.终止的引入，肯定带来了代码重入的疑问。咱们知道，这可以经过设定优先级、信号量/临界区等等方法来处置。UEFI是经过什么方法呢？TPL和IRQL的相似和区别又是什么呢？

2.UEFI内核还不允许多线程，咱们假设须要参与多线程调度，仅仅依托时钟终止，够不够用呢？

3.OS应用缺页意外可以调度内存到硬盘上和成功Lazyloading等等适用的性能。UEFI的SMM内核也开启了缺页意外，然而却为了另外一个目标，你能看出是为了什么吗？

终止体系其余文章：

欢迎大家关注本专栏和用微信扫描下方二维码参与微信群众号"UEFIBlog"，在那里有最新的文章。关注群众号，留言资料，有一些地下芯片资料供下载。

标签： 计算机迷信、 计算机技术、 计算机、

本文地址： https://yihaiquanyi.com/article/bace998bc22e03198fb0.html

上一篇：executiveExecution什么是Speculative为什...
下一篇：UEFI和UFFI引导有什么区别UEFI和UEFI论坛...