[toc]
Linux中斷一網(wǎng)打盡 —— 中斷及其初始化
前情提要
通過本文您可以了解到如下內(nèi)容：
- Linux 中斷是什么，如何分類，能干什么？
- Linux 中斷在計算機啟動各階段是如何初始化的？
中斷是什么
既然叫中斷, 那我們首先就會想到這個中斷是中斷誰？想一想計算機最核心的部分是什么？沒錯， CPU， 計算機上絕大部分的計算都在CPU中完成，因此這個中斷也就是中斷CPU當前的運行，讓CPU轉而先處理這個引起中斷的事件，通常來說這個中斷的事件比較緊急，處理完畢后再繼續(xù)執(zhí)行之前被中斷的task。比如，我們敲擊鍵盤，CPU就必須立即響應這個操作，不然我們打字就全變成了慢動作～。說白了中斷其實就是一種主動通知機制，如果中斷源不主動通知，那想知道其發(fā)生了什么事情，只能一次次地輪詢了，白白耗費CPU。
中斷的分類
大的方向上一般分為兩大類：同步中斷和異步中斷，按Intel的說法，將異步中斷稱為中斷，將同步中斷稱為異常。
異步中斷
主要是指由CPU以外的硬件產(chǎn)生的中斷，比如鼠標，鍵盤等。它的特點是相對CPU來說隨時隨機發(fā)生，事先完全沒有預兆，不可預期的。異步中斷發(fā)生時，CPU基本上都正在執(zhí)行某條指令。
異步中斷可分為可屏蔽和不可屏蔽兩種，字如其義不用多解釋。
同步中斷
主要是指由CPU在執(zhí)行命令過程中產(chǎn)生的異常，它一定是在CPU執(zhí)行完一條命令后才會發(fā)出，產(chǎn)生于CPU內(nèi)部。按其被CPU處理后返回位置的不同，我們將同步中斷分為故障(fault), 陷阱(trap)和終止(abort)三類。我們通過一個表格來作下對比區(qū)分：
| 中斷分類 | 特點 | 處理完畢后的返回位置 | 例子 |
|---|---|---|---|
| 故障(fault) | 潛在可能恢復的錯誤 | 重新執(zhí)行引起此故障的指令 | 缺頁中斷 |
| 陷阱(trap) | 為了實現(xiàn)某種功能有意而為之發(fā)生的錯誤 | 執(zhí)行引發(fā)當前陷阱的指令的下一條指令 | 系統(tǒng)調(diào)用 |
| 終止(abort) | 不可恢復的錯誤 | 沒有返回，進程將被終止 |
兩點說明：
處理完畢后的返回位置：發(fā)生異常時，CPU最終會進入到相應的異常處理程序中（簡單說就是CPU需要執(zhí)行一次跳轉）在執(zhí)行具體操作前會設置好的異常處理完成后跳轉回的CS:IP, 即代碼段寄存器和程序指針寄存器，不同類型的異常其設置的CS:IP不同而已；有些分類方法還會有一種叫
可編程異常的，比如說把系統(tǒng)調(diào)用算作這一類，也可以。但是如果按處理完畢后的返回位置來說系統(tǒng)調(diào)用是可以歸入陷阱這一類的。
硬件中斷的管理模型
我們都知道CPU上只有有限多的腳針，負責與外部通訊，比如有數(shù)據(jù)線，地址線等，也有中斷線，但一般只有兩條NMI(不可屏蔽中斷線)和INTR(可屏蔽中斷線)， 新的CPU有LINT0和LINT1腳針。那您會問了，電腦上有那么多外設，CPU就這兩根線，怎么接收這么多外設的中斷信號呢？確實，因此CPU找了一個管理這些眾多中斷的代理人——中斷控制器。
就目前我們使用的SMP多核架構里，我們經(jīng)常使用高級可編程中斷控制器APIC， 老式的 8259A 可編程中斷控制器大家有興趣可自行搜索。
APIC分為兩部分，IO APIC和Local APIC，從名字上我們就可略知一二。
IO APIC: 用來連接各種外設的硬件控制器，接收其發(fā)送的中斷請求信號，然后將其傳送到Local APIC, 這個IO APIC一般會封裝在主板南板芯片上;
Local APIC: 基本上集成在了CPU里， 向CPU通知中斷發(fā)生。
-
放張網(wǎng)上的圖：
ioapic.jpg
中斷的初始化
Linux 啟動流程
中斷的初始化是穿插在Linux本身啟動和初始化過程中的，因此我們在這里簡要說一下Linux本身的初始化。
- 64位Linux啟動大的方向上需要經(jīng)過
實模式 -> 保護模式 -> 長模式第三種模式的轉換; - 電源接通，CPU啟動并重置各寄存器后運行于實模式下，CS:IP加載存儲于ROM中的一跳轉指令，跳轉到BIOS中；
- BIOS啟動，硬件自測，讀取MRB;
- BIOS運行第一階段引導程序，第一階段引導程序運行第二階段引導程序，通常是 grub;
- Grub開始引導內(nèi)核運行;
- 相關初始化后進行保護模式，再進入長模式，內(nèi)核解壓縮；
- 體系無關初始化部分;
- 體系相關初始化部分;
總結了一張圖，僅供參考：
中斷描述符表
外設千萬種，CPU統(tǒng)統(tǒng)不知道。所有的中斷到了CPU這里就只是一個中斷號，然后初始化階段設置好中斷號到中斷處理程序的對應關系，CPU獲取到一個中斷號后，查到對應的中斷處理程序調(diào)用就好了。
這兩者的對應關系最后會抽象成了中斷向量表， 現(xiàn)在叫 IDT中斷描述符表。
中斷的第一次初始化
實模式下的初始化
- 上面那張Linux啟動流程圖如果你仔細看的話會發(fā)現(xiàn)在BIOS程序加載運行時，在實模式下也有一個BIOS的中斷向量表，這個中斷向量表提供了一些類似于BIOS的系統(tǒng)調(diào)用一樣的方法。比如Linux在初始化時需要獲取物理內(nèi)存的詳情，就 是調(diào)用了BIOS的相應中斷來獲取的。見下圖：
中斷的第二次初始化
在進入到
保護模式后，會全新初始化一個空的中斷描述符表 IDT, 供 kernel 使用;-
Linux Kernel提供256個大小的中斷描述符表
#define IDT_ENTRIES 256 gate_desc idt_table[IDT_ENTRIES] __page_aligned_bss;
中斷的第三次初始化
-
在進入到
長模式后，在x86_64_start_kernel先初始化前32個異常類型的中斷(即上面定義的 idt_table 的前32項)；void __init idt_setup_early_handler(void) { int i; for (i = 0; i < NUM_EXCEPTION_VECTORS; i++) set_intr_gate(i, early_idt_handler_array[i]); load_idt(&idt_descr); }其中
early_idt_handler_array這個數(shù)組放置了32個異常類型的中斷處理程序，我們先看一下它的定義：const char early_idt_handler_array[32][9];二維數(shù)組，每一個
early_idt_handler_array[i]有9個字節(jié)。這個
early_idt_handler_array的初始化很有意思，它用AT&T的匯編代碼完成，在文件arch/x86/kernel/head_64.S中：ENTRY(early_idt_handler_array) i = 0 .rept NUM_EXCEPTION_VECTORS .if ((EXCEPTION_ERRCODE_MASK >> i) & 1) == 0 UNWIND_HINT_IRET_REGS pushq $0 # Dummy error code, to make stack frame uniform .else UNWIND_HINT_IRET_REGS offset=8 .endif pushq $i # 72(%rsp) Vector number jmp early_idt_handler_common UNWIND_HINT_IRET_REGS i = i + 1 .fill early_idt_handler_array + i*EARLY_IDT_HANDLER_SIZE - ., 1, 0xcc .endr UNWIND_HINT_IRET_REGS offset=16 END(early_idt_handler_array)這段匯編循環(huán)遍歷32次來初始化每一個
early_idt_handler_array[i], 也就是填充它的9個字節(jié)：其中2個字節(jié)是壓棧錯誤碼指令，2個字節(jié)是壓棧向量號指令，余下的5個字節(jié)是函數(shù)跳轉指令（jmp early_idt_handler_common）。由此我們可以看出，這前32個異常類型的中斷處理函數(shù)最終都會調(diào)用到early_idt_handler_common, 這個函數(shù)這里就不貼它的代碼了，我們說下它的大致流程：a. 先將各寄存器的值壓棧保存； b. 如果是 缺頁異常，就調(diào)用 `early_make_patable`; c. 如果是 其他異常，就調(diào)用 `early_fixup_exception`; -
體系結構相關的中斷初始化
這也是一次部分初始化，它發(fā)生在
start_kernel的setup_arch中，即發(fā)生在 Linux 啟動流程中的體系結構初始化部分。這部分實際上是更新上面已初始化的32個異常類中的X86_TRAP_DB(1號, 用于debug)和X86_TRAP_BP(3號, 用于debug時的斷點);static const __initconst struct idt_data early_idts[] = { INTG(X86_TRAP_DB, debug), SYSG(X86_TRAP_BP, int3), }; void __init idt_setup_early_traps(void) { idt_setup_from_table(idt_table, early_idts, ARRAY_SIZE(early_idts), true); load_idt(&idt_descr); }debug和int3這兩個匯編實現(xiàn)的中斷處理程序這里我們就不詳述了。 -
更新
X86_TRAP_PF 缺頁異常的中斷處理程序void __init idt_setup_early_pf(void) { idt_setup_from_table(idt_table, early_pf_idts, ARRAY_SIZE(early_pf_idts), true); } static const __initconst struct idt_data early_pf_idts[] = { INTG(X86_TRAP_PF, page_fault), }; -
在
trap_init中調(diào)用idt_setup_traps更新部分異常的中斷處理程序：void __init idt_setup_traps(void) { idt_setup_from_table(idt_table, def_idts, ARRAY_SIZE(def_idts), true); } static const __initconst struct idt_data def_idts[] = { INTG(X86_TRAP_DE, divide_error), INTG(X86_TRAP_NMI, nmi), INTG(X86_TRAP_BR, bounds), INTG(X86_TRAP_UD, invalid_op), INTG(X86_TRAP_NM, device_not_available), INTG(X86_TRAP_OLD_MF, coprocessor_segment_overrun), INTG(X86_TRAP_TS, invalid_TSS), INTG(X86_TRAP_NP, segment_not_present), INTG(X86_TRAP_SS, stack_segment), INTG(X86_TRAP_GP, general_protection), INTG(X86_TRAP_SPURIOUS, spurious_interrupt_bug), INTG(X86_TRAP_MF, coprocessor_error), INTG(X86_TRAP_AC, alignment_check), INTG(X86_TRAP_XF, simd_coprocessor_error), #ifdef CONFIG_X86_32 TSKG(X86_TRAP_DF, GDT_ENTRY_DOUBLEFAULT_TSS), #else INTG(X86_TRAP_DF, double_fault), #endif INTG(X86_TRAP_DB, debug), #ifdef CONFIG_X86_MCE INTG(X86_TRAP_MC, &machine_check), #endif SYSG(X86_TRAP_OF, overflow), #if defined(CONFIG_IA32_EMULATION) SYSG(IA32_SYSCALL_VECTOR, entry_INT80_compat), #elif defined(CONFIG_X86_32) SYSG(IA32_SYSCALL_VECTOR, entry_INT80_32), #endif }; -
在
trap_init中調(diào)用idt_setup_ist_traps更新部分異常的中斷處理程序,看到這里您可能問，上面不是調(diào)用了
idt_setup_traps，怎么這時又調(diào)用idt_setup_ist_traps? 這兩者有什么區(qū)別？說起來話有點長，我們盡量從流程上給大家講清楚，但不深入到具體的細節(jié)。-
想說明這個問題，我們先來講下棧這個東西:
a. 首先每個進程都有自己的用戶態(tài)棧，對應進程虛擬地址空間內(nèi)的stack部分，用于進程在用戶態(tài)變量申請，函數(shù)調(diào)用等操作；
b. 除了用戶態(tài)棧，每個進程在創(chuàng)建時(內(nèi)核對應創(chuàng)建 task_struct結構)同時會創(chuàng)建對應的內(nèi)核棧，這里進程由用戶態(tài)進入到內(nèi)核態(tài)執(zhí)行函數(shù)時，相應的所用的棧也會切換到內(nèi)核棧；
c. 如果內(nèi)核進入到中斷處理程序，早期的kernel針對中斷處理程序的執(zhí)行會使用當前中斷task的內(nèi)核棧，這里有存在一定的問題，存在棧溢出的風險。舉個例子，如果在中斷處理程序里又發(fā)生了異常中斷，此時會觸發(fā)
double fault，但其在處理過程中依然要使用當前task的內(nèi)核棧，并且當前task內(nèi)核棧已滿，double fault無法被正確處理。為了解決這樣的內(nèi)部，linux kernel引出了獨立的內(nèi)核棧，針對SMP系統(tǒng)，它還是pre-cpu的。我們來看一下其初始化：void irq_ctx_init(int cpu) { union irq_ctx *irqctx; if (hardirq_ctx[cpu]) return; // 硬中斷獨立棧 irqctx = (union irq_ctx *)&hardirq_stack[cpu * THREAD_SIZE]; irqctx->tinfo.task = NULL; irqctx->tinfo.cpu = cpu; irqctx->tinfo.preempt_count = HARDIRQ_OFFSET; irqctx->tinfo.addr_limit = MAKE_MM_SEG(0); hardirq_ctx[cpu] = irqctx; //軟中斷獨立棧 irqctx = (union irq_ctx *)&softirq_stack[cpu * THREAD_SIZE]; irqctx->tinfo.task = NULL; irqctx->tinfo.cpu = cpu; irqctx->tinfo.preempt_count = 0; irqctx->tinfo.addr_limit = MAKE_MM_SEG(0); softirq_ctx[cpu] = irqctx; printk("CPU %u irqstacks, hard=%p soft=%p\n", cpu, hardirq_ctx[cpu], softirq_ctx[cpu]); }可以看到還特別貼心地為softirq也開辟了單獨的棧。
-
在x86_64位系統(tǒng)中，還引入了一種新的棧配置：IST(Interrupt Stack Table)。目前Linux kernel中每個cpu最多支持7個IST，可以通過tss.ist[]來訪問。
-
現(xiàn)在我們再來看
idt_setup_ist_traps，其實就是重新初始化一個異常處理，讓這些異常處理使用IST作為中斷棧。void __init idt_setup_ist_traps(void) { idt_setup_from_table(idt_table, ist_idts, ARRAY_SIZE(ist_idts), true); } static const __initconst struct idt_data ist_idts[] = { ISTG(X86_TRAP_DB, debug, IST_INDEX_DB), ISTG(X86_TRAP_NMI, nmi, IST_INDEX_NMI), ISTG(X86_TRAP_DF, double_fault, IST_INDEX_DF), #ifdef CONFIG_X86_MCE ISTG(X86_TRAP_MC, &machine_check, IST_INDEX_MCE), #endif }; #define ISTG(_vector, _addr, _ist) \ G(_vector, _addr, _ist + 1, GATE_INTERRUPT, DPL0, __KERNEL_CS)其中
IST_INDEX_DBIST_INDEX_NMIIST_INDEX_DFIST_INDEX_MCE就是要使用的ist[]的索引。
-
剩下的最后一部分就是硬件中斷的初始化了，它同樣在
start_kernel中執(zhí)行：early_irq_init(); init_IRQ();這部分具體細節(jié)我們在Linux中斷一網(wǎng)打盡(2) - IDT及中斷處理的實現(xiàn)介紹。
