arm smmu的原理與smmu驅(qū)動iommu框架

1: arm smmu的原理

1.1: smmu 基本知識

如上圖所示，smmu 的作用和mmu 類似，mmu作用是替cpu翻譯頁表將進(jìn)程的虛擬地址轉(zhuǎn)換成cpu可以識別的物理地址。同理，smmu的作用就是替設(shè)備將dma請求的地址，翻譯成設(shè)備真正能用的物理地址，但是當(dāng)smmu bypass的時(shí)候，設(shè)備也可以直接使用物理地址來進(jìn)行dma；

1.2: smmu 的數(shù)據(jù)結(jié)構(gòu)

smmu的重要的用來dma地址翻譯的數(shù)據(jù)結(jié)構(gòu)都是放在內(nèi)存中的，由smmu的寄存器保存著這些表在內(nèi)存中的基地址，首先就是StreamTable(STE)，這ste 表既包含stage1的翻譯表結(jié)構(gòu)也包含stage2的翻譯結(jié)構(gòu)，所謂stage1負(fù)責(zé)VA 到 PA的轉(zhuǎn)換，stage2負(fù)責(zé)IPA到PA的轉(zhuǎn)換。

接下來我們重點(diǎn)看一下這個(gè)STE的結(jié)構(gòu)，到底在內(nèi)存中是如何組織的；

對smmu來說，一個(gè)smmu可以給很多個(gè)設(shè)備服務(wù)，所以，在smmu里面為了區(qū)分的對每個(gè)設(shè)備進(jìn)行管理，smmu 給每一個(gè)設(shè)備一個(gè)ste entry，那設(shè)備如何定位這個(gè)ste entry呢？對于一個(gè)smmu來說，我們給他所管理的每個(gè)設(shè)備一個(gè)唯一的device id，這個(gè)device id又叫 stream id；對于設(shè)備比較少的情況下，我們的smmu 的ste 表，很明顯只需要是1維數(shù)組就可以了，如下圖：

注意，這里ste采用線性表并不是真是由設(shè)備的數(shù)量來決定的，而是寫在smmu 的ID0寄存器中的，也就是配置好了的，對于華為鯤鵬上的smmu基本不采用這種結(jié)構(gòu)；

對于設(shè)備數(shù)量較多的情況下，我們?yōu)榱?smmu 更加的皮實(shí)點(diǎn)，可以采用兩層ste表的結(jié)構(gòu)，如下圖：

這里的結(jié)構(gòu)其實(shí)很類似我們的mmu的頁表了，在arm smmu v3 我們第一層的目錄desc的目錄結(jié)夠，大小采用8（STRTAB_SPLIT）位，也就是stream id的高8位，stream id剩下的低位全部用來尋址第二層真正的ste entry;

介紹完了 smmu 中管理設(shè)備的ste的表的兩種結(jié)構(gòu)后，我們來看看這個(gè)ste表的具體結(jié)構(gòu)是啥，里面有啥奧秘呢：

如上如所示，紅框中就是smmu中一個(gè)ste entry的全貌了，從紅框中能看出來，這個(gè)ste entry同時(shí)管理了stage1 和 stage2的數(shù)據(jù)結(jié)構(gòu)；其中config是表示ste有關(guān)的配置項(xiàng)，這個(gè)不需要理解也不需要記憶，不知道的查一下smmuv3的手冊即可，里面的VMID是指虛擬機(jī)ID,這里我們重點(diǎn)關(guān)注一下S1ContextPtr和S2TTB。

首先我們來說S1ContextPtr：

這個(gè)S1ContextPtr指向的一個(gè)Context Descriptor的目錄結(jié)構(gòu)，這張圖為了好理解只畫了一個(gè)，在我們arm中，如果沒有虛擬機(jī)參與的話，無論是cpu還是smmu地址翻譯都是從va->pa/iova->pa，我們稱之為stage1，也就是不涉及虛擬，只是一階段翻譯而已。

重要的CD表，讀到這里，你是不是會問一個(gè)問題，在smmu中我們?yōu)楹我褂肅D表呢？原因是這樣的，一個(gè)smmu可以管理很多設(shè)備，所以用ste表來區(qū)分每個(gè)設(shè)備的數(shù)據(jù)結(jié)構(gòu)，每個(gè)設(shè)備一個(gè)ste表。那如果每個(gè)設(shè)備上跑了多個(gè)任務(wù)，這些任務(wù)又同時(shí)使用了不同的page table 的話，那咋管理呢？對不對？所以smmu 采用了CD表來管理每個(gè)page table；

看一看cd 表的查找規(guī)則：

先說另外一個(gè)重要的概念：SubstreamID(pasid)，這個(gè)叫substreamid又稱之為pasid，也是非常簡單的概念，既然有表了，那也得有id來協(xié)助查找啊，所以就出來了這個(gè)id，從這里也可以看出來，道理都一樣，用了表了就有id 啊！

CD表，在smmu中也是可以是線性的或者兩級的，這個(gè)都是在smmu 寄存器中配置好了的，由smmu驅(qū)動來讀去，進(jìn)行按對應(yīng)的位進(jìn)行分級，和ste表一樣的原理；

介紹了兩個(gè)基本的也重要的數(shù)據(jù)結(jié)構(gòu)后我，smmu是在支持虛擬化的時(shí)候，可以同時(shí)進(jìn)行stage1 和 stage2的翻譯的，如下圖所示：

當(dāng)我們在虛擬機(jī)的guest中啟用smmu的時(shí)候，smmu是需要同時(shí)開啟stage1 和 stage2的，當(dāng)然了，smmu 也是可以進(jìn)行bypass的；

1.3:smmu的地址翻譯流程

如上圖，基本可以很明顯的概括出了一個(gè)外設(shè)請求 smmu 的地址翻譯的基本流程，當(dāng)一個(gè)外設(shè)需要dma的物理地址的時(shí)候，開始請求smmu的地址翻譯，這時(shí)候外設(shè)給 smmu 3個(gè)比較重要的信息，分別是：streamid：協(xié)助smmu 找到管理外設(shè)的ste entry，subsreamid：當(dāng)找到ste entry后，協(xié)助smmu找到對應(yīng)的cd 表，通過這兩個(gè)id smmu 就可以找到對應(yīng)的iopge table了，smmu找到page table 后結(jié)合外設(shè)提交過來的最后一個(gè)信息iova，即可開始進(jìn)行地址翻譯；

smmu 也有tlb的緩存，smmu首先會根據(jù)當(dāng)前cd表中存放的asid來查查tlb緩存中有沒有對應(yīng)page table的緩存，這里其實(shí)和mmu找頁表的原理是一樣的，不過多解釋了，很簡單；

上圖中的地址翻譯還涉及到了stage2，這里不解釋了，smmu涉及到虛擬化的過程比較復(fù)雜，這個(gè)有機(jī)會再解釋；

2 smmu驅(qū)動與iommu框架

2.1：smmu v3驅(qū)動初始化

簡單的介紹了上面的兩個(gè)重要表以及smmu內(nèi)部的基本的查找流程后，我們現(xiàn)在來看看在linux內(nèi)核中，smmu驅(qū)動是如何完成初始化的過程，借著這個(gè)分析，我們看看smmu里的重要的幾種隊(duì)列：

smmuv3的在內(nèi)核中的代碼路徑：drivers/iommu/arm-smmu-v3.c:

上面是smmu驅(qū)動中初始化流程的前半部分，從中可以很容易看出來，內(nèi)核中每個(gè)smmu都有一個(gè)結(jié)構(gòu)體struct arm_smmu_device來管理，實(shí)際上初始化的流程就是在填充著個(gè)結(jié)構(gòu)?？瓷蠄D，首先就是從slub/slab中分配一個(gè)對象空間，隨后一個(gè)比較重要的是函數(shù)

arm_smmu_device_dt_probe 和 arm_smmu_device_acpi_probe，這倆函數(shù)會從dts中的smmu節(jié)點(diǎn)和acpi的smmu配置表中讀取一些smmu中斷等等屬性；

隨后調(diào)用函數(shù)platform_get_resource來從dts或者apci表中讀取smmu的寄存器的基地址，這個(gè)很重要，后續(xù)所有的初始化都是圍繞著個(gè)配置來的；

繼續(xù)看剩下的部分，開頭很容易看出來，要讀取smmu的幾個(gè)中斷號，smmu 硬件給軟件消息有隊(duì)列buffer，smmu硬件通過中斷的方式讓smmu驅(qū)動從隊(duì)列buffer中取消息，我們一一介紹：

第一個(gè)eventq中斷，smmu的一個(gè)隊(duì)列叫event隊(duì)列，這個(gè)隊(duì)列是給掛在smmu上的platform設(shè)備用的，當(dāng)platform設(shè)備使用smmu翻譯dma 的iova的時(shí)候，如果發(fā)生了一場smmu會首先將異常的消息填到event隊(duì)列中，隨后上報(bào)一個(gè)eventq的中斷給 smmu 驅(qū)動，smmu驅(qū)動接到這個(gè)中斷后，開始執(zhí)行中斷處理程序，從event隊(duì)列中將異常的消息讀出來，顯示異常；

另外一個(gè)priq中斷時(shí)給pri隊(duì)列用的，這個(gè)隊(duì)列是專門給掛在smmu上的pcie類型的設(shè)備用的，具體的流程其實(shí)是和event隊(duì)列是一樣的，這里不多解釋了；

最后一個(gè)是gerror中斷，如果smmu 在執(zhí)行過程中，發(fā)生了不可恢復(fù)的嚴(yán)重錯(cuò)誤，smmu會報(bào)告一個(gè)gerror中斷給smmu驅(qū)動，就不需要隊(duì)列了，因?yàn)楸旧韲?yán)重錯(cuò)誤了，直接中斷上來處理了；

完成了3個(gè)中斷初始化后（具體的中斷初始化映射流程，不在這里介紹，改天單獨(dú)寫個(gè)中斷章節(jié)介紹），smmu 驅(qū)動此時(shí)已經(jīng)完成了smmu管理結(jié)構(gòu)的分配，以及smmu配置的讀取，smmu的寄存器的映射，以及smmu中斷的初始化，這些都搞完后，smmu驅(qū)動開始讀取提前寫死在 smmu 寄存器中的各種配置，將配置bit位讀取出來放到struct arm_smm_device的數(shù)據(jù)結(jié)構(gòu)中，函數(shù)arm_smmu_device_hw_probe函數(shù)就負(fù)責(zé)讀smmu的硬件寄存器；

當(dāng)我們寄存器配置讀取完畢后，這時(shí)候我們知道了哪些信息呢？會有這個(gè)smmu支持二級ste還是一級的ste，二級的cd還有1級的cd，這個(gè)smmu支持的物理也大小，iova和pa的地址位數(shù)等等；這些頭填在arm_smmu_device的features的字段里面；

基本信息讀出來后，我們是不是可開始初始化數(shù)據(jù)結(jié)構(gòu)了？答案是肯定的啦，看看函數(shù)arm_smmu_init_structures;

從上面的數(shù)據(jù)結(jié)構(gòu)初始化的函數(shù)可以看出來，smmu驅(qū)動主要負(fù)責(zé)初始化兩種數(shù)據(jù)結(jié)構(gòu)，一個(gè)strtab(stream table的簡寫)，另外一個(gè)種是隊(duì)列的內(nèi)存分配和初始化；我們首先來看看隊(duì)列的：

從上面可以看出來，smmu驅(qū)動主要初始化3個(gè)隊(duì)列：cmdq，evtq，priq;這里不再進(jìn)一步解釋了，避免陷入函數(shù)細(xì)節(jié)分析；

最后我們來看看smmu 的strtab的初始化：

從上圖可以看出來，首先判斷我們需要初始化一級的還是二級的stream table，這里依據(jù)就是上面的硬件寄存器中讀取出來的；

我們首先看看函數(shù)arm_smmu_init_strtab_linear 函數(shù)：

對于線性的stream table表來說smmu 驅(qū)動會將調(diào)用dma alloc接口將stream table 需要的所有空間都一把分配完畢了，并且將所有的ste entry項(xiàng)都給預(yù)先的初始化成bypass的模式，具體的就不深入看了，比較簡單，設(shè)置bit；

隨后我們來看看函數(shù)：

arm_smmu_init_strtab_2lvl；

我們可以思考一個(gè)問題：我們真的需要將所有的ste entry都個(gè)創(chuàng)造出來嗎？很顯然，不是的，smmu驅(qū)動的初始化正是基于這種原理，僅僅只會初始化第一級的ste目錄項(xiàng)，其實(shí)這里就是類似頁表的初始化了也只是先初始化了目錄項(xiàng)；函數(shù)中dma alloc coherent就是負(fù)責(zé)分配第一級的目錄項(xiàng)的，分配的大小是多大呢？我們可以看一下有一個(gè)關(guān)鍵的宏STRTAB_SPLIT，這個(gè)宏目前在smmu驅(qū)動中是8位，也就是預(yù)先會分配2^8個(gè)目錄項(xiàng)，每個(gè)目錄項(xiàng)的大小是固定的；

我們可以看到里面還調(diào)用了一個(gè)函數(shù)arm_smmu_init_l1_strtab函數(shù)，這里就是我們空間分配完了，總該給這些目錄項(xiàng)給初始化一下吧，這里就不深入進(jìn)去看了；

到此為止，我們已經(jīng)將基本的數(shù)據(jù)結(jié)構(gòu)初始化給簡要的講完了；我們接著看smmu驅(qū)動初始化的剩下的，見下圖：

上圖是smmu 驅(qū)動初始化的剩下的部分，我們可以看出來里面第一個(gè)函數(shù)是arm_smmu_device_reset，這個(gè)函數(shù)是干嘛的呢，我們前面是不是已經(jīng)給這個(gè)smmu在內(nèi)存中分配了幾個(gè)隊(duì)列和stream table的目錄項(xiàng)？那這些數(shù)據(jù)結(jié)構(gòu)的基地址總該讓smmu知道吧？這個(gè)函數(shù)就是將這些基地址給放到smmu的控制寄存器中的；當(dāng)前我們需要的東西給初始化完后，smmu驅(qū)動接下來就是將smmu的基本數(shù)據(jù)結(jié)構(gòu)注冊到上層的iommu抽象框架里，讓iommu結(jié)構(gòu)能夠調(diào)用到smmu，這個(gè)在后面再說。

2.2 smmu 與 iommu關(guān)系

2.2.1 兩者的結(jié)構(gòu)關(guān)系

smmu 和 iommu 是何種關(guān)系呢？在我們的硬件體系中，能夠有能力完成設(shè)備iova 到 pa轉(zhuǎn)換的有很多，例如有intel iommu, amd的iommu ,arm的smmu等等，不一一枚舉了；那這些不同的硬件架構(gòu)不會都作為一個(gè)獨(dú)立的子系統(tǒng)，所以，在linux 內(nèi)核中 抽象了一層 iommu 層，由iommu層給各個(gè)外部設(shè)備驅(qū)動提供結(jié)構(gòu)，隱藏底層的不同的架構(gòu)；如圖所示：

由上圖可以很明顯的看出來，各個(gè)架構(gòu)的smmu驅(qū)動是如何使如何和iommu框架對接的，iommu框架通過不同架構(gòu)的ops來調(diào)用到底層真正的驅(qū)動接口；

我們可以問自己一個(gè)問題：底層的驅(qū)動是如何對接到上層的？

接下來我們來看看進(jìn)入內(nèi)核代碼來幫我們解開疑惑；

如上圖是smmu 驅(qū)動初始化的最后一部分，對于底層的每一個(gè)smmu結(jié)構(gòu)在iommu框架層中都一有一個(gè)唯一的一個(gè)結(jié)構(gòu)體表示：struct iommu_device，上圖中函數(shù)iommu_device_register所完成的任務(wù)就是將我們所初始化好的iommu結(jié)構(gòu)體給注冊到iommu層的鏈表中，統(tǒng)一管理起來；最后我們根據(jù)smmu所掛載的是pcie外設(shè)，還是platform外設(shè)，將和個(gè)smmu綁定到不同的總線類型上；

2.2.2 iommu的重要結(jié)構(gòu)與ops

iommu 層通過ops來調(diào)用底層硬件驅(qū)動，我們來看看smmu v3硬件驅(qū)動提供了哪些ops call：

上圖就是smmu v3 硬件驅(qū)動提供的所有的調(diào)用函數(shù)；

既然到了iommu層，那我們也會涉及到兩種概念的管理，一種是設(shè)備如何管理，另外一種是smmu 提供的io page table如何管理；

為了分別管理，這兩種概念，iommu 框架提供了兩種結(jié)構(gòu)體，一個(gè)是 struct iommu_domain 這個(gè)結(jié)構(gòu)抽象出了一個(gè)domain的結(jié)構(gòu)，用來代表底層的arm_smmu_domain，其實(shí)最核心的是管理這個(gè)domian所擁有的io page table。另外一個(gè)是sruct iommu_group這個(gè)結(jié)構(gòu)是用來管理設(shè)備的，多個(gè)設(shè)備可以在一個(gè)iommu group中，以此來共享一個(gè)iopage table; 我們看一個(gè)網(wǎng)絡(luò)上的圖即可很明白的表明其中的關(guān)系：

這張圖中很明顯的寫出來smmu domian和 iommu的domain的關(guān)系，以及iommu group的作用；不再過多解釋。

2.3 dma iova 與iommu

dma 和 iommu 息息相關(guān)，iommu的產(chǎn)生其實(shí)很大的原因就是避免dma的時(shí)候直接使用物理地址而導(dǎo)致的不安全性，所以就產(chǎn)生了iova, 我們在調(diào)用dma alloc的時(shí)候，首先在io 的地址空間中分配你一個(gè)iova, 然后在iommu所管理的頁表中做好iova 和dma alloc時(shí)候產(chǎn)生的物理地址進(jìn)行映射；外設(shè)在進(jìn)行dma的時(shí)候，只需要使用iova即可完成dma動作；

那我們?nèi)绾瓮瓿蒬ma alloc的時(shí)候iova到pa的映射的呢？

dma_alloc ->__iommu_alloc_attrs

在__iommu_alloc_attrs函數(shù)中調(diào)用iommu_dma_alloc函數(shù)來完成iova和pa的分配與映射；

iommu_dma_alloc->__iommu_dma_alloc_pages,

首先會調(diào)用者個(gè)函數(shù)來完成物理頁面的分配：

函數(shù)__iommu_dma_alloc_pages中完成的任務(wù)是頁面分配，iommu_dma_alloc_iova完成的就是iova的分配，最后iommu_map_sg即可完成iova到pa的映射；

linux 采用rb tree來管理每一段的iova區(qū)間，這其實(shí)和我們的虛擬內(nèi)存的分配是類似的，我們的vma的管理也是這樣的；

我們接下來在來看看iova的釋放過程，這個(gè)釋放的過程，我們是可以看到看到strict 個(gè) non-strict模式的最核心的區(qū)別的：

老規(guī)矩，直接擼代碼，我們看到dma的釋放流程也是很簡單的，首先將iova和pa進(jìn)行解映射處理，然后將iova結(jié)構(gòu)給釋放掉；

看圖中解映射的部分就是在iommu_unmap_fast流程中處理的就是調(diào)用iommu的unmap然后通過ops 調(diào)用到arm smmu v3驅(qū)動的 unmap函數(shù)：__iommu_dma_unmap->iommu_unmap_fast->(ops->unmap: arm_smmu_unmap)->arm_lpae_unmap；

我們進(jìn)入函數(shù)arm_lpae_unmap中看看是干啥的，見下圖：

這個(gè)函數(shù)采用遞歸的方式來查找io page table的最后一項(xiàng)，當(dāng)找到的時(shí)候，我們可注意看代碼行613~622行，其中613~620行是當(dāng)我們的iommu采用默認(rèn)的non strict模式的時(shí)候，我們是不用立馬對tlb進(jìn)行無效化的；但是當(dāng)我們采用strict模式的時(shí)候，我們還是會將tlb給刷新一下，調(diào)用函數(shù)io_pgtable_tlb_add_flush給smmu寫入一個(gè)tlb無效化的指令；

那我們采用non-strict模式的時(shí)候是如何刷新tlb的呢？秘密就在函數(shù)iommu_dma_free_iova函數(shù)中見下圖：

我們可以看到，如果采用non-strict的模式的時(shí)候，我們是放到一個(gè)隊(duì)列中的，當(dāng)我們的隊(duì)列滿的時(shí)候，會調(diào)用函數(shù)iovad->flush_cb，

這個(gè)函數(shù)指針，最終會調(diào)用到函數(shù)：iommu_dma_flush_iotlb_all，來進(jìn)行全局的tlb的刷新，smmu無需執(zhí)行太多的指令了；

2.4 smmu和iommu的bypass

方式一：將iommu 給徹底給bypass掉，linux 提供了iommu.passthrough command line的選項(xiàng)，這個(gè)選項(xiàng)配置上后，dma 默認(rèn)不會走iommu，而是走傳統(tǒng)的swiotlb方式的dma；

方式二：smmu v3的驅(qū)動默認(rèn)支持驅(qū)動參數(shù)配置，disable_bypass，在系統(tǒng)中是默認(rèn)關(guān)閉bypass的，我們可以通過這個(gè)來將某個(gè)smmu給bypass掉；

方式三：acpi 或者dts中不配置相應(yīng)的smmu節(jié)點(diǎn)，比較粗暴的辦法。

3.smmu 的PMCG

ARM的SMMU提供了性能相關(guān)的統(tǒng)計(jì)寄存器(Performance Monitor Counter Groups - PMCG)，首先要確定使用的系統(tǒng)里有arm_smmuv3_pmu這個(gè)模塊，或者它已經(jīng)被編譯進(jìn)內(nèi)核。

這個(gè)模塊的代碼在內(nèi)核目錄kernel/drivers/perf/arm_smmuv3_pmu.c,內(nèi)核配置是: CONFIG_ARM_SMMU_V3_PMU；

smmu pmcg 社區(qū)的patch 連接：

https://lwn.net/Articles/784040/

詳細(xì)用法可以參見 社區(qū)pmcg的補(bǔ)丁文檔，里面內(nèi)容很簡單。
責(zé)任編輯：YYX