快速鏈接:
.
👉👉👉 個人博客筆記導讀目錄(全部) 👈👈👈


說明: 在默認的情況下，本文講述的是armv8 aarch64體系，optee 3.12.0代碼


思考
1、在設置VBAR_EL1之前，會發生異常嗎？ 如果發生異常會怎樣？
2、VBAR_EL1中寫入的是物理地址還是虛擬地址
3、開啟MMU之后，要不要切換異常向量表？
4、optee中有幾張異常向量表?
5、unmask中斷在enable mmu之前還是之后？一定是這個順序嗎？為什么？

在之前的一篇文章中(optee3.14中的異常向量表解讀–中斷處理解讀)，我們介紹了optee中的異常向量表，也知道其基地址(虛擬地址)的設置是在一個比較靠后的位置，設置了VBAR_EL1 = thread_excp_vect，以及從CPU的設置在一個更加靠后的位置。

那么今天我們再來深度探究一下在設置VBAR_EL1 = thread_excp_vect之前的時候，發生異常了會怎么辦？

• _start -->(2) ：在(2)之前，所有的中斷都是MASK的，CPU不會taken這個中斷。
• (2) -->(4) : 在(2)處unmask serror中斷，在(4)處mask掉了所有中斷。所以在(2)—>(4)期間系統是可以接受serror中斷，此時來的serror中斷，cpu將跳轉到serror異常向量。事實上reset_vect_table向量表中的所有向量，都是死循環

(optee_os/core/arch/arm/kernel/entry_a64.S)SErrorSP0:b SErrorSP0check_vector_size SErrorSP0 .....

• (4)—>std call(yiled call) ：(4)已經退出了optee的初始化程序。在下次cpu進入optee時，如果是fast call，那么不會Unmask中斷。如果是std call(yiled call)則會Unmask所有中斷，那么此時發生的任何異常，cpu將跳轉到thread_excp_vect向量表

總結寫在最后:
1、optee中有兩張異常向量表：reset_vect_table和thread_excp_vect，其中：

• reset_vect_table：是開機初始化時使用的一張向量表，里面所有的offset的實現都是死循環(相當于未實現)，且在開機初始化階段，只開啟了serror中斷，所以也不會發生sync、irq、fiq。
• thread_excp_vect：開機初始化完成之前設置的向量表。當optee退出之后，下次再因為std call（yield call）進來，會Unmask所有中斷，此時會使用這張向量表.

2、寫入到VBAR_EL1的是物理地址還是虛擬地址?

• reset_vect_table： 因為是在整個開機初始化的大部分區間，都要使用該向量表，且包括enable_mmu之前和enable_mmu之后的區間。所以答案也是不言而喻，reset_vect_table的地址一定是VA=PA，那么是怎樣做到的呢？ 細心的同學可能會發現identity_map關鍵字，其實就是將該表存放到了section端，切實一一映射的一塊區間。

LOCAL_FUNC reset_vect_table , :, .identity_map

• reset_vect_table： reset_vect_table其實定義成了一個函數原型，向量offset對其的方式填入到這個函數體內。最后再將函數地址寫入到vbar_el1，故此處是虛擬地址.

總結

以上是生活随笔為你收集整理的optee中关于异常向量表、中断等的深入思考的全部內容，希望文章能夠幫你解決所遇到的問題。

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