1

中斷是什么

既然叫中斷, 那我們首先就會想到這個中斷是中斷誰？想一想計算機最核心的部分是什么？沒錯， CPU， 計算機上絕大部分的計算都在CPU中完成，因此這個中斷也就是中斷CPU當前的運行，讓CPU轉而先處理這個引起中斷的事件，通常來說這個中斷的事件比較緊急，處理完畢后再繼續執行之前被中斷的task。比如，我們敲擊鍵盤，CPU就必須立即響應這個操作，不然我們打字就全變成了慢動作～說白了中斷其實就是一種主動通知機制，如果中斷源不主動通知，那想知道其發生了什么事情，只能一次次地輪詢了，白白耗費CPU。

2

中斷的分類

大的方向上一般分為兩大類：同步中斷和異步中斷，按Intel的說法，將異步中斷稱為中斷，將同步中斷稱為異常。

異步中斷

主要是指由CPU以外的硬件產生的中斷，比如鼠標，鍵盤等。它的特點是相對CPU來說隨時隨機發生，事先完全沒有預兆，不可預期的。異步中斷發生時，CPU基本上都正在執行某條指令。

異步中斷可分為可屏蔽和不可屏蔽兩種，字如其義不用多解釋。

同步中斷

主要是指由CPU在執行命令過程中產生的異常，它一定是在CPU執行完一條命令后才會發出，產生于CPU內部。按其被CPU處理后返回位置的不同，我們將同步中斷分為故障(fault), 陷阱(trap)和終止(abort)三類。我們通過一個表格來作下對比區分：

兩點說明：

• 處理完畢后的返回位置：發生異常時，CPU最終會進入到相應的異常處理程序中(簡單說就是CPU需要執行一次跳轉)在執行具體操作前會設置好的異常處理完成后跳轉回的CS:IP, 即代碼段寄存器和程序指針寄存器，不同類型的異常其設置的CS:IP不同而已；

• 有些分類方法還會有一種叫可編程異常的，比如說把系統調用算作這一類，也可以。但是如果按處理完畢后的返回位置來說系統調用是可以歸入陷阱這一類的。

3

面對如此眾多的服務器

我們都知道CPU上只有有限多的腳針，負責與外部通訊，比如有數據線，地址線等，也有中斷線，但一般只有兩條NMI(不可屏蔽中斷線)和INTR(可屏蔽中斷線)， 新的CPU有LINT0和LINT1腳針。那您會問了，電腦上有那么多外設，CPU就這兩根線，怎么接收這么多外設的中斷信號呢？確實，因此CPU找了一個管理這些眾多中斷的代理人——中斷控制器。

就目前我們使用的SMP多核架構里，我們經常使用高級可編程中斷控制器APIC， 老式的 8259A 可編程中斷控制器大家有興趣可自行搜索。

APIC分為兩部分，IO APIC和Local APIC，從名字上我們就可略知一二。

• IO APIC: 用來連接各種外設的硬件控制器，接收其發送的中斷請求信號，然后將其傳送到Local APIC, 這個IO APIC一般會封裝在主板南板芯片上;

• Local APIC: 基本上集成在了CPU里， 向CPU通知中斷發生。

放張網上的圖：

4

中斷的初始化

Linux的啟動流程

中斷的初始化是穿插在Linux本身啟動和初始化過程中的，因此我們在這里簡要說一下Linux本身的初始化。

• 64位Linux啟動大的方向上需要經過?實模式 -> 保護模式 -> 長模式?第三種模式的轉換;

• 電源接通，CPU啟動并重置各寄存器后運行于實模式下，CS:IP加載存儲于ROM中的一跳轉指令，跳轉到BIOS中；

• BIOS啟動，硬件自測，讀取MRB;

• BIOS運行第一階段引導程序，第一階段引導程序運行第二階段引導程序，通常是 grub;

• Grub開始引導內核運行;

• 相關初始化后進行保護模式，再進入長模式，內核解壓縮；

• 體系無關初始化部分;

• 體系相關初始化部分;

總結了一張圖，僅供參考：

中斷描述符表

外設千萬種，CPU統統不知道。所有的中斷到了CPU這里就只是一個中斷號，然后初始化階段設置好中斷號到中斷處理程序的對應關系，CPU獲取到一個中斷號后，查到對應的中斷處理程序調用就好了。

這兩者的對應關系最后會抽象成了中斷向量表， 現在叫 IDT中斷描述符表。

中斷的第一次初始化

實模式下的初始化

• 上面那張Linux啟動流程圖如果你仔細看的話會發現在BIOS程序加載運行時，在實模式下也有一個BIOS的中斷向量表，這個中斷向量表提供了一些類似于BIOS的系統調用一樣的方法。比如Linux在初始化時需要獲取物理內存的詳情，就 是調用了BIOS的相應中斷來獲取的。見下圖：

中斷的第二次初始化

• 在進入到保護模式后，會全新初始化一個空的中斷描述符表 IDT, 供 kernel 使用;

• Linux Kernel提供256個大小的中斷描述符表

#define IDT_ENTRIES 256gate_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這個數組放置了32個異常類型的中斷處理程序，我們先看一下它的定義：

const char early_idt_handler_array[32][9];

二維數組，每一個early_idt_handler_array[i]有9個字節。

這個 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=16END(early_idt_handler_array)

這段匯編循環遍歷32次來初始化每一個early_idt_handler_array[i], 也就是填充它的9個字節：其中2個字節是壓棧錯誤碼指令，2個字節是壓棧向量號指令，余下的5個字節是函數跳轉指令(jmp early_idt_handler_common)。由此我們可以看出，這前32個異常類型的中斷處理函數最終都會調用到early_idt_handler_common, 這個函數這里就不貼它的代碼了，我們說下它的大致流程：

a. 先將各寄存器的值壓棧保存；b. 如果是 缺頁異常，就調用 `early_make_patable`; c. 如果是 其他異常，就調用 `early_fixup_exception`;

體系結構相關的中斷初始化:

這也是一次部分初始化，它發生在 start_kernel的setup_arch中，即發生在 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這兩個匯編實現的中斷處理程序這里我們就不詳述了。

更新?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中調用 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中調用?idt_setup_ist_traps更新部分異常的中斷處理程序

看到這里您可能問，上面不是調用了idt_setup_traps，怎么這時又調用idt_setup_ist_traps? 這兩者有什么區別？說起來話有點長，我們盡量從流程上給大家講清楚，但不深入到具體的細節。

想說明這個問題，我們先來講下棧這個東西:

a. ?首先每個進程都有自己的用戶態棧，對應進程虛擬地址空間內的stack部分，用于進程在用戶態變量申請，函數調用等操作；

b. 除了用戶態棧，每個進程在創建時(內核對應創建 task_struct結構)同時會創建對應的內核棧，這里進程由用戶態進入到內核態執行函數時，相應的所用的棧也會切換到內核棧；

c. 如果內核進入到中斷處理程序，早期的kernel針對中斷處理程序的執行會使用當前中斷task的內核棧，這里有存在一定的問題，存在棧溢出的風險。舉個例子，如果在中斷處理程序里又發生了異常中斷，此時會觸發double fault，但其在處理過程中依然要使用當前task的內核棧，并且當前task內核棧已滿，double fault無法被正確處理。為了解決這樣的內部，linux kernel引出了獨立的內核棧，針對SMP系統，它還是pre-cpu的。我們來看一下其初始化,還特別貼心地為softirq也開辟了單獨的棧:

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]);}

2. 在x86_64位系統中，還引入了一種新的棧配置：IST(Interrupt Stack Table)。目前Linux kernel中每個cpu最多支持7個IST，可以通過tss.ist[]來訪問。

3. 現在我們再來看idt_setup_ist_traps，其實就是重新初始化一個異常處理，讓這些異常處理使用IST作為中斷棧。其中 IST_INDEX_DB IST_INDEX_NMI IST_INDEX_DF IST_INDEX_MCE就是要使用的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)

剩下的最后一部分就是硬件中斷的初始化了，它同樣在start_kernel中執行：

early_irq_init();init_IRQ();

這部分具體細節我們在Linux中斷一網打盡(2) - IDT及中斷處理的實現介紹。

本文轉載自云計算

---

往期精彩回顧

2019年度精選文章

httprunner使用總結

全國新型肺炎實時動態

---

360技術公眾號

技術干貨|一手資訊|精彩活動

掃碼關注我們

總結

以上是生活随笔為你收集整理的32获取外部中断状态_Linux中断一网打尽(1) — 中断及其初始化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。