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


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


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

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

那么今天我們?cè)賮砩疃忍骄恳幌略谠O(shè)置VBAR_EL1 = thread_excp_vect之前的時(shí)候，發(fā)生異常了會(huì)怎么辦？

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

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

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

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

• reset_vect_table：是開機(jī)初始化時(shí)使用的一張向量表，里面所有的offset的實(shí)現(xiàn)都是死循環(huán)(相當(dāng)于未實(shí)現(xiàn))，且在開機(jī)初始化階段，只開啟了serror中斷，所以也不會(huì)發(fā)生sync、irq、fiq。
• thread_excp_vect：開機(jī)初始化完成之前設(shè)置的向量表。當(dāng)optee退出之后，下次再因?yàn)閟td call（yield call）進(jìn)來，會(huì)Unmask所有中斷，此時(shí)會(huì)使用這張向量表.

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

• reset_vect_table： 因?yàn)槭窃谡麄€(gè)開機(jī)初始化的大部分區(qū)間，都要使用該向量表，且包括enable_mmu之前和enable_mmu之后的區(qū)間。所以答案也是不言而喻，reset_vect_table的地址一定是VA=PA，那么是怎樣做到的呢？ 細(xì)心的同學(xué)可能會(huì)發(fā)現(xiàn)identity_map關(guān)鍵字，其實(shí)就是將該表存放到了section端，切實(shí)一一映射的一塊區(qū)間。

LOCAL_FUNC reset_vect_table , :, .identity_map

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。