基礎知識很重要。
原博客鏈接：http://blog.sina.com.cn/s/blog_5ffeae360100ftwt.html
保護模式下Intel 80x86 CPU 硬件中斷過程
大學學操作系統原理的時候，感覺進程和文件似乎是介紹最多的兩塊內容，但慢慢發現，要想理解清楚操作系統的工作機制，如果按知識學習的先後順序排，中斷應當是比較靠前的纔對，只有理解了中斷的機制，纔有可能真正理解進程，文件系統，設備等等其他的概念。
中斷實際上爲OS裏很多概念的具體實現提供了一個基本的保證，比如進程的調度、設備的訪問、用戶態和內核態的切換，各種異常的處理等等都需要中斷的參與，甚至連對臨界資源的安全訪問也需要中斷的支持，這足以說明中斷是可以作爲一個瞭解操作系統工作原理和具體機制的入口點的，而不僅僅只是作爲相關書籍裏獨立的一個章節來理解。
由於中斷的機制和實現是和硬件密切相關的，這裏只總結一下Intel 80x86系列CPU的中斷在硬件層面上處理過程。
1. 中斷和異常的概念區別
Intel的官方文檔[1]裏將中斷和異常理解爲兩種中斷當前程序執行的不同機制。這是中斷和異常的共同點。不同點在於：
中斷(interrupt)是異步的事件，典型的比如由I/O設備觸發；
異常(exception)是同步的事件，典型的比如處理器執行某條指令時發現出錯了等等。
中斷又可以分爲可屏蔽中斷和非可屏蔽中斷，異常又分爲故障、陷阱和異常中止3種，它們的具體區別很多書籍和官方文檔都解釋的比較清楚這裏不再贅述。
關於它們的區別有兩點是需要注意的：
1）平常所說的屏蔽中斷是不包括異常的，即異常不會因爲CPU的IF位被清（關中斷，指令：cli）而受影響，比如缺頁異常，即使關了中斷也會觸發CPU的處理。
2）通常說的int 80h這種系統調用使用的中斷方式實際上硬件上是理解爲異常處理的，因此也不會被屏蔽掉，這也很好理解，int80h這種中斷方式是程序裏主動觸發的，對於CPU來說屬於同步事件，因此也就屬於異常的範疇。
2. 中斷（異常）處理過程
需要明確的一點是CPU對於中斷和異常的具體處理機制本質上是完全一致的，即：
當CPU收到中斷或者異常的信號時，它會暫停執行當前的程序或任務，通過一定的機制跳轉到負責處理這個信號的相關處理程序中，在完成對這個信號的處理後再跳回到剛纔被打斷的程序或任務中。這裏只描述保護模式下的處理過程，搞清楚了保護模式下的處理過程（更復雜），實模式下的處理機制也就容易理解了。
具體的處理過程如下：
0）中斷響應的事前準備：
系統要想能夠應對各種不同的中斷信號，總的來看就是需要知道每種信號應該由哪個中斷服務程序負責以及這些中斷服務程序具體是如何工作的。系統只有事前對這兩件事都知道得很清楚，才能正確地響應各種中斷信號和異常。
[a]系統將所有的中斷信號統一進行了編號（一共256個：0～255），這個號稱爲中斷向量，具體哪個中斷向量表示哪種中斷有的是規定好的，也有的是在給定範圍內自行設定的。
中斷向量和中斷服務程序的對應關係主要是由IDT（中斷向量表）負責。操作系統在IDT中設置好各種中斷向量對應的中斷描述符（一共有三類中斷門描述符：任務門、中斷門和陷阱門），留待CPU查詢使用。而IDT本身的位置是由idtr保存的，當然這個地址也是由OS填充的。
下面的示意圖顯示了IDT的基本結構和IDTR是如何指示IDT的位置和長度的：
[b]中斷服務程序具體負責處理中斷（異常）的代碼是由軟件，也就是操作系統實現的，這部分代碼屬於操作系統內核代碼。也就是說從CPU檢測中斷信號到加載中斷服務程序以及從中斷服務程序中恢復執行被暫停的程序，這個流程基本上是硬件確定下來的，而具體的中斷向量和服務程序的對應關係設置和中斷服務程序的內容是由操作系統確定的。
1）CPU檢查是否有中斷/異常信號
CPU在執行完當前程序的每一條指令後，都會去確認在執行剛纔的指令過程中中斷控制器（如：8259A）是否發送中斷請求過來，如果有那麼CPU就會在相應的時鐘脈衝到來時從總線上讀取中斷請求對應的中斷向量[2]。
對於異常和系統調用那樣的軟中斷，因爲中斷向量是直接給出的，所以和通過IRQ（中斷請求）線發送的硬件中斷請求不同，不會再專門去取其對應的中斷向量。
2）根據中斷向量到IDT表中取得處理這個向量的中斷程序的段選擇符
CPU根據得到的中斷向量到IDT表裏找到該向量對應的中斷描述符，中斷描述符裏保存着中斷服務程序的段選擇符。
3）根據取得的段選擇符到GDT中找相應的段描述符
CPU使用IDT查到的中斷服務程序的段選擇符從GDT中取得相應的段描述符，段描述符裏保存了中斷服務程序的段基址和屬性信息，此時CPU就得到了中斷服務程序的起始地址。
這裏，CPU會根據當前cs寄存器裏的CPL和GDT的段描述符的DPL，以確保中斷服務程序是高於當前程序的，如果這次中斷是編程異常（如：int80h系統調用），那麼還要檢查CPL和IDT表中中斷描述符的DPL，以保證當前程序有權限使用中斷服務程序，這可以避免用戶應用程序訪問特殊的陷阱門和中斷門[3]。
如下圖顯示了從中斷向量到GDT中相應中斷服務程序起始位置的定位方式:
4）CPU根據特權級的判斷設定即將運行的中斷服務程序要使用的棧的地址
CPU會根據CPL和中斷服務程序段描述符的DPL信息確認是否發生了特權級的轉換，比如當前程序正運行在用戶態，而中斷程序是運行在內核態的，則意味着發生了特權級的轉換，這時CPU會從當前程序的TSS信息（該信息在內存中的首地址存在TR寄存器中）裏取得該程序的內核棧地址，即包括ss和esp的值，並立即將系統當前使用的棧切換成新的棧。這個棧就是即將運行的中斷服務程序要使用的棧。緊接着就將當前程序使用的ss,esp壓到新棧中保存起來。
6）保護當前程序的現場
CPU開始利用棧保護被暫停執行的程序的現場：依次壓入當前程序使用的eflags，cs，eip，errorCode（如果是有錯誤碼的異常）信息。
官方文檔[1]給出的棧變化的示意圖如下：
7）跳轉到中斷服務程序的第一條指令開始執行
CPU利用中斷服務程序的段描述符將其第一條指令的地址加載到cs和eip寄存器中，開始執行中斷服務程序。這意味着先前的程序被暫停執行，中斷服務程序正式開始工作。
8）中斷服務程序處理完畢，恢復執行先前中斷的程序
在每個中斷服務程序的最後，必須有中斷完成返回先前程序的指令，這就是iret（或iretd）。程序執行這條返回指令時，會從棧裏彈出先前保存的被暫停程序的現場信息，即eflags,cs,eip重新開始執行。如果存在特權級轉換還會彈出ss和esp，這樣也意味着棧也被切換回原先使用的棧了。
這裏有個地方需要注意：如果此次處理的是帶有錯誤碼(errorCode)的異常，CPU在恢復先前程序的現場時，並不會彈出errorCode，也就是說CPU似乎忘記了曾經壓過一個errorCode入棧，因此要求相關的中斷服務程序在調用iret返回之前需要主動彈出errorCode。
參考書目：
[1] Intel 64 and IA-32 Architectures Software Developers ManualVolume 1 Basic Architecture
[2] 《微型計算機接口技術及應用》，華中科技大學出版社，劉樂善 主編
[3] 《深入理解Linux內核》，第三版，中國電力出版社