• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            天下

            記錄修行的印記

            中斷及中斷處理過程

            中斷及中斷處理過程
            1. 中斷和異常的概念區別
               Intel的官方文檔里將中斷和異常理解為兩種中斷當前程序執行的不同機制。這是中斷和異常的共同點。不同點在于:
               中斷(interrupt)是異步的事件,典型的比如由I/O設備觸發;異常(exception)是同步的事件,典型的比如處理器執行某條指令時發現出錯了等等。
               中斷又可以分為可屏蔽中斷和非可屏蔽中斷,異常又分為故障、陷阱和異常中止3種,它們的具體區別很多書籍和官方文檔都解釋的比較清楚這里不再贅述。
            關于它們的區別有兩點是需要注意的:
            1)平常所說的屏蔽中斷是不包括異常的,即異常不會因為CPU的IF位被清(關中斷,指令:cli)而受影響,比如缺頁異常,即使關了中斷也會觸發CPU的處理。
            2)通常說的int 80h這種系統調用使用的中斷方式實際上硬件上是理解為異常處理的,因此也不會被屏蔽掉,這也很好理解,int 80h這種中斷方式是程序里主動觸發的,對于CPU來說屬于同步事件,因此也就屬于異常的范疇。
            2. 中斷(異常)處理過程
               需要明確的一點是CPU對于中斷和異常的具體處理機制本質上是完全一致的,即:
            當CPU收到中斷或者異常的信號時,它會暫停執行當前的程序或任務,通過一定的機制跳轉到負責處理這個信號的相關處理程序中,在完成對這個信號的處理后再跳回到剛才被打斷的程序或任務中。這里只描述保護模式下的處理過程,搞清楚了保護模式下的處理過程(更復雜),實模式下的處理機制也就容易理解了。
            具體的處理過程如下:
            0)中斷響應的事前準備:
            系統要想能夠應對各種不同的中斷信號,總的來看就是需要知道每種信號應該由哪個中斷服務程序負責以及這些中斷服務程序具體是如何工作的。系統只有事前對這兩件事都知道得很清楚,才能正確地響應各種中斷信號和異常。
            [a]系統將所有的中斷信號統一進行了編號(一共256個:0~255),這個號稱為中斷向量,具體哪個中斷向量表示哪種中斷有的是規定好的,也有的是在給定范圍內自行設定的。  
            中斷向量和中斷服務程序的對應關系主要是由IDT(中斷向量表)負責。操作系統在IDT中設置好各種中斷向量對應的中斷描述符(一共有三類中斷門描述符:任務門、中斷門和陷阱門),留待CPU查詢使用。而IDT本身的位置是由idtr保存的,當然這個地址也是由OS填充的。
            [b]中斷服務程序具體負責處理中斷(異常)的代碼是由軟件,也就是操作系統實現的,這部分代碼屬于操作系統內核代碼。也就是說從CPU檢測中斷信號到加載中斷服務程序以及從中斷服務程序中恢復執行被暫停的程序,這個流程基本上是硬件確定下來的,而具體的中斷向量和服務程序的對應關系設置和中斷服務程序的內容是由操作系統確定的。
            1)CPU檢查是否有中斷/異常信號
               CPU在執行完當前程序的每一條指令后,都會去確認在執行剛才的指令過程中中斷控制器(如:8259A)是否發送中斷請求過來,如果有那么CPU就會在相應的時鐘脈沖到來時從總線上讀取中斷請求對應的中斷向量[2]。
            對于異常和系統調用那樣的軟中斷,因為中斷向量是直接給出的,所以和通過IRQ(中斷請求)線發送的硬件中斷請求不同,不會再專門去取其對應的中斷向量。
            2)根據中斷向量到IDT表中取得處理這個向量的中斷程序的段選擇符
               CPU根據得到的中斷向量到IDT表里找到該向量對應的中斷描述符,中斷描述符里保存著中斷服務程序的段選擇符。
            3)根據取得的段選擇符到GDT中找相應的段描述符
               CPU使用IDT查到的中斷服務程序的段選擇符從GDT中取得相應的段描述符,段描述符里保存了中斷服務程序的段基址和屬性信息,此時CPU就得到了中斷服務程序的起始地址。
               這里,CPU會根據當前cs寄存器里的CPL和GDT的段描述符的DPL,以確保中斷服務程序是高于當前程序的,如果這次中斷是編程異常(如:int 80h系統調用),那么還要檢查CPL和IDT表中中斷描述符的DPL,以保證當前程序有權限使用中斷服務程序,這可以避免用戶應用程序訪問特殊的陷阱門和中斷門[3]。
            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重新開始執行。

            posted on 2011-11-16 17:25 天下 閱讀(6643) 評論(0)  編輯 收藏 引用 所屬分類: kernel & Driver

            <2013年3月>
            242526272812
            3456789
            10111213141516
            17181920212223
            24252627282930
            31123456

            導航

            統計

            常用鏈接

            留言簿(4)

            隨筆分類(378)

            隨筆檔案(329)

            鏈接

            最新隨筆

            搜索

            最新評論

            午夜精品久久久久成人| 国产99精品久久| 2020久久精品亚洲热综合一本| 欧美亚洲国产精品久久| 久久精品国产亚洲AV无码麻豆 | 久久激情亚洲精品无码?V| 日日狠狠久久偷偷色综合0| 偷偷做久久久久网站| 久久精品无码专区免费东京热| 久久精品国产精品亚洲精品| 国产69精品久久久久观看软件| 久久精品嫩草影院| 亚洲va久久久噜噜噜久久| 欧洲性大片xxxxx久久久| 久久91精品国产91久久户| 综合人妻久久一区二区精品| 国产精品99久久久久久猫咪| 成人午夜精品无码区久久 | 久久丫忘忧草产品| 久久99国产精一区二区三区| 久久夜色精品国产亚洲| 办公室久久精品| 精品久久777| 91精品国产色综合久久| 狠狠色丁香久久婷婷综合| 蜜臀久久99精品久久久久久| 国产99久久九九精品无码| 久久综合给合久久狠狠狠97色| 欧美久久久久久| 香蕉99久久国产综合精品宅男自 | 伊人情人综合成人久久网小说 | 亚洲国产成人精品女人久久久 | 亚洲色欲久久久久综合网 | 日产精品久久久久久久性色 | 久久亚洲国产午夜精品理论片| 亚洲中文久久精品无码| 亚洲色婷婷综合久久| 伊人久久大香线蕉综合影院首页| 久久婷婷午色综合夜啪| 久久综合视频网站| 免费精品久久天干天干|