0
  • 聊天消息
  • 系統(tǒng)消息
  • 評(píng)論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會(huì)員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識(shí)你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

arm smmu的原理

Linux閱碼場(chǎng) ? 來(lái)源:Linuxer ? 作者:Linuxer ? 2020-10-09 10:43 ? 次閱讀

1: arm smmu的原理

1.1: smmu 基本知識(shí)

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

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

smmu的重要的用來(lái)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)換。

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

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

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

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

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

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

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

首先我們來(lái)說(shuō)S1ContextPtr:

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

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

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

先說(shuō)另外一個(gè)重要的概念:SubstreamID(pasid),這個(gè)叫substreamid又稱之為pasid,也是非常簡(jiǎn)單的概念,既然有表了,那也得有id來(lái)協(xié)助查找啊,所以就出來(lái)了這個(gè)id,從這里也可以看出來(lái),道理都一樣,用了表了就有id ??!

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

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

當(dāng)我們?cè)谔摂M機(jī)的guest中啟用smmu的時(shí)候,smmu是需要同時(shí)開(kāi)啟stage1 和 stage2的,當(dāng)然了,smmu 也是可以進(jìn)行bypass的;

1.3:smmu的地址翻譯流程

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

smmu 也有tlb的緩存,smmu首先會(huì)根據(jù)當(dāng)前cd表中存放的asid來(lái)查查tlb緩存中有沒(méi)有對(duì)應(yīng)page table的緩存,這里其實(shí)和mmu找頁(yè)表的原理是一樣的,不過(guò)多解釋了,很簡(jiǎn)單;

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

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

2.1:smmu v3驅(qū)動(dòng)初始化

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

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

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

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

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

繼續(xù)看剩下的部分,開(kāi)頭很容易看出來(lái),要讀取smmu的幾個(gè)中斷號(hào),smmu 硬件給軟件消息有隊(duì)列buffer,smmu硬件通過(guò)中斷的方式讓smmu驅(qū)動(dòng)從隊(duì)列buffer中取消息,我們一一介紹:

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

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

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

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

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

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

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

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

最后我們來(lái)看看smmu 的strtab的初始化:

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

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

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

隨后我們來(lái)看看函數(shù):

arm_smmu_init_strtab_2lvl;

我們可以思考一個(gè)問(wèn)題:我們真的需要將所有的ste entry都個(gè)創(chuàng)造出來(lái)嗎?很顯然,不是的,smmu驅(qū)動(dòng)的初始化正是基于這種原理,僅僅只會(huì)初始化第一級(jí)的ste目錄項(xiàng),其實(shí)這里就是類似頁(yè)表的初始化了也只是先初始化了目錄項(xiàng);函數(shù)中dma alloc coherent就是負(fù)責(zé)分配第一級(jí)的目錄項(xiàng)的,分配的大小是多大呢?我們可以看一下有一個(gè)關(guān)鍵的宏STRTAB_SPLIT,這個(gè)宏目前在smmu驅(qū)動(dòng)中是8位,也就是預(yù)先會(huì)分配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)初始化給簡(jiǎn)要的講完了;我們接著看smmu驅(qū)動(dòng)初始化的剩下的,見(jiàn)下圖:

上圖是smmu 驅(qū)動(dòng)初始化的剩下的部分,我們可以看出來(lái)里面第一個(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ū)動(dòng)接下來(lái)就是將smmu的基本數(shù)據(jù)結(jié)構(gòu)注冊(cè)到上層的iommu抽象框架里,讓iommu結(jié)構(gòu)能夠調(diào)用到smmu,這個(gè)在后面再說(shuō)。

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)不會(huì)都作為一個(gè)獨(dú)立的子系統(tǒng),所以,在linux 內(nèi)核中 抽象了一層 iommu 層,由iommu層給各個(gè)外部設(shè)備驅(qū)動(dòng)提供結(jié)構(gòu),隱藏底層的不同的架構(gòu);如圖所示:

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

我們可以問(wèn)自己一個(gè)問(wèn)題:底層的驅(qū)動(dòng)是如何對(duì)接到上層的?

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

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

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

iommu 層通過(guò)ops來(lái)調(diào)用底層硬件驅(qū)動(dòng),我們來(lái)看看smmu v3硬件驅(qū)動(dòng)提供了哪些ops call:

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

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

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

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

2.3 dma iova 與iommu

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

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

dma_alloc ->__iommu_alloc_attrs

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

iommu_dma_alloc->__iommu_dma_alloc_pages,

首先會(huì)調(diào)用者個(gè)函數(shù)來(lái)完成物理頁(yè)面的分配:

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

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

我們接下來(lái)在來(lái)看看iova的釋放過(guò)程,這個(gè)釋放的過(guò)程,我們是可以看到看到strict 個(gè) non-strict模式的最核心的區(qū)別的:

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

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

我們進(jìn)入函數(shù)arm_lpae_unmap中看看是干啥的,見(jiàn)下圖:

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

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

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

這個(gè)函數(shù)指針,最終會(huì)調(diào)用到函數(shù):iommu_dma_flush_iotlb_all,來(lái)進(jìn)行全局的tlb的刷新,smmu無(wú)需執(zhí)行太多的指令了;

2.4 smmu和iommu的bypass

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

方式二:smmu v3的驅(qū)動(dòng)默認(rèn)支持驅(qū)動(dòng)參數(shù)配置,disable_bypass,在系統(tǒng)中是默認(rèn)關(guān)閉bypass的,我們可以通過(guò)這個(gè)來(lái)將某個(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;

原文標(biāo)題:ARM SMMU的原理與IOMMU

文章出處:【微信公眾號(hào):Linuxer】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。

責(zé)任編輯:haq

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場(chǎng)。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問(wèn)題,請(qǐng)聯(lián)系本站處理。 舉報(bào)投訴
  • ARM
    ARM
    +關(guān)注

    關(guān)注

    134

    文章

    9098

    瀏覽量

    367707
收藏 人收藏

    評(píng)論

    相關(guān)推薦

    利用Arm Kleidi技術(shù)實(shí)現(xiàn)PyTorch優(yōu)化

    PyTorch 是一個(gè)廣泛應(yīng)用的開(kāi)源機(jī)器學(xué)習(xí) (ML) 庫(kù)。近年來(lái),Arm 與合作伙伴通力協(xié)作,持續(xù)改進(jìn) PyTorch 的推理性能。本文將詳細(xì)介紹如何利用 Arm Kleidi 技術(shù)提升 Arm
    的頭像 發(fā)表于 12-23 09:19 ?172次閱讀
    利用<b class='flag-5'>Arm</b> Kleidi技術(shù)實(shí)現(xiàn)PyTorch優(yōu)化

    Arm原生Google Chrome增強(qiáng)Windows on Arm性能

    微軟 Windows 10 和 Windows 11 集成了 Arm 原生支持,這保證了為 Windows 開(kāi)發(fā)更多 Arm 原生應(yīng)用。這種支持提供了額外的工具,以簡(jiǎn)化應(yīng)用移植、增強(qiáng)應(yīng)用性能并降低功耗。因此,很多公司目前正在為 Windows 投資
    的頭像 發(fā)表于 12-17 10:25 ?239次閱讀

    Arm成功將Arm KleidiAI軟件庫(kù)集成到騰訊自研的Angel 機(jī)器學(xué)習(xí)框架

    Arm 與騰訊攜手合作,成功將 Arm KleidiAI 軟件庫(kù)集成到騰訊自研的 Angel 機(jī)器學(xué)習(xí)框架。 ? 借助 KleidiAI 解鎖卓越性能、能效和可移植性,騰訊混元大模型能夠?qū)崿F(xiàn)更快
    的頭像 發(fā)表于 11-24 15:33 ?699次閱讀

    Arm推出GitHub平臺(tái)AI工具

    專為 GitHub Copilot 設(shè)計(jì)的 Arm 擴(kuò)展程序,可加速?gòu)脑频竭吘墏?cè)基于 Arm 平臺(tái)的開(kāi)發(fā)。
    的頭像 發(fā)表于 11-01 13:50 ?294次閱讀

    Arm全面設(shè)計(jì)助力Arm架構(gòu)生態(tài)發(fā)展

    Arm 控股有限公司(納斯達(dá)克股票代碼:ARM,以下簡(jiǎn)稱 Arm)近日分享了Arm 全面設(shè)計(jì) (Arm Total Design) 生態(tài)項(xiàng)目
    的頭像 發(fā)表于 10-21 09:58 ?388次閱讀

    Arm如何賦能無(wú)處不在的AI

    作為人工智能 (AI) 的創(chuàng)新基礎(chǔ),眾多企業(yè)都在使用通用且應(yīng)用廣泛的 Arm 計(jì)算平臺(tái)。迄今為止,合作伙伴基于 Arm 架構(gòu)的芯片出貨量已逾 2,800 億顆。如今,Arm 已為各類技術(shù)領(lǐng)域的 AI 應(yīng)用提供支持,這也是為何 A
    的頭像 發(fā)表于 09-14 09:38 ?541次閱讀

    ARM 主板:計(jì)算的未來(lái)

    近年來(lái),計(jì)算領(lǐng)域發(fā)生了重大轉(zhuǎn)變。傳統(tǒng)的基于x86的處理器幾十年來(lái)一直占據(jù)市場(chǎng)主導(dǎo)地位,但現(xiàn)在基于ARM的處理器正在獲得關(guān)注并徹底改變行業(yè)。ARM主板處于這場(chǎng)革命的前沿,提供全新級(jí)別的性能、效率
    的頭像 發(fā)表于 06-21 17:16 ?546次閱讀
    <b class='flag-5'>ARM</b> 主板:計(jì)算的未來(lái)

    Arm推出AI優(yōu)化的Arm終端CSS以及新的Arm Kleidi軟件

    Arm 終端計(jì)算子系統(tǒng) (CSS) 作為新的計(jì)算解決方案,結(jié)合了 Armv9 架構(gòu)的優(yōu)勢(shì),以及基于三納米工藝節(jié)點(diǎn),經(jīng)過(guò)驗(yàn)證和證實(shí)為生產(chǎn)就緒的新 Arm CPU 和 GPU 實(shí)現(xiàn),可賦能芯片合作伙伴快速創(chuàng)新,
    的頭像 發(fā)表于 05-30 11:33 ?664次閱讀
    <b class='flag-5'>Arm</b>推出AI優(yōu)化的<b class='flag-5'>Arm</b>終端CSS以及新的<b class='flag-5'>Arm</b> Kleidi軟件

    ArmArm Neoverse計(jì)算子系統(tǒng)(CSS):Arm Neoverse CSS V3和Arm Neoverse CSS N3

    Arm宣布了兩款新的Arm Neoverse計(jì)算子系統(tǒng)(CSS),它們基于“迄今為止最好的一代Neoverse技術(shù)”。是什么讓這些新產(chǎn)品在擁擠的計(jì)算技術(shù)領(lǐng)域脫穎而出? Arm的兩個(gè)新Arm
    的頭像 發(fā)表于 04-24 17:53 ?1085次閱讀
    <b class='flag-5'>Arm</b>新<b class='flag-5'>Arm</b> Neoverse計(jì)算子系統(tǒng)(CSS):<b class='flag-5'>Arm</b> Neoverse CSS V3和<b class='flag-5'>Arm</b> Neoverse CSS N3

    什么是ARM架構(gòu)?ARM主板有哪些優(yōu)勢(shì)?

    ARM主板不僅在物聯(lián)網(wǎng)設(shè)備中廣泛應(yīng)用,還在嵌入式系統(tǒng)和工控領(lǐng)域等方面展現(xiàn)了強(qiáng)大的性能和靈活性。
    的頭像 發(fā)表于 03-29 14:11 ?1327次閱讀

    Arm v9芯片新架構(gòu)揭秘

    從中長(zhǎng)期來(lái)看,隨著單芯片 ARM 核數(shù)增加、基于 ARM 架構(gòu)芯片數(shù)量的上升以及ARM 應(yīng)用場(chǎng)景的增加,公司仍將保持增長(zhǎng)。據(jù)公司公告數(shù)據(jù)顯示,2023 財(cái)年,高端芯片采用 ARM 的核
    發(fā)表于 02-27 14:14 ?5431次閱讀
    <b class='flag-5'>Arm</b> v9芯片新架構(gòu)揭秘

    Arm 更新 Neoverse 產(chǎn)品路線圖,實(shí)現(xiàn)基于 Arm 平臺(tái)的人工智能基礎(chǔ)設(shè)施

    新聞重點(diǎn): Arm 宣布推出兩款基于全新第三代 Neoverse IP 構(gòu)建的新的 Arm Neoverse 計(jì)算子系統(tǒng) Arm Neoverse CSS V3 是高性能 V 系列產(chǎn)品組合中的首款
    發(fā)表于 02-22 11:41 ?385次閱讀

    ARM股價(jià)4日暴漲1.3倍 孫正義靠Arm打了一場(chǎng)翻身仗

    ARM股價(jià)4日暴漲1.3倍 孫正義靠Arm打了一場(chǎng)翻身仗 在2月7日至2月12日間的短短三個(gè)交易日內(nèi),Arm股價(jià)上漲逾90%。在Arm公布了2024財(cái)年第三財(cái)季財(cái)報(bào)數(shù)據(jù)后,
    的頭像 發(fā)表于 02-18 15:22 ?1251次閱讀

    智原與Arm合作提供基于Arm Neoverse CSS的設(shè)計(jì)服務(wù)

    ASIC設(shè)計(jì)服務(wù)暨IP研發(fā)銷售廠商智原科技(Faraday Technology Corporation,TWSE:3035)正式宣布成為Arm Total Design的設(shè)計(jì)服務(wù)合作伙伴,凸顯了其
    的頭像 發(fā)表于 01-10 16:29 ?749次閱讀

    arm中斷是怎么實(shí)現(xiàn)的

    ARM中斷的實(shí)現(xiàn)是通過(guò)中斷控制器和異常模式實(shí)現(xiàn)的。ARM處理器通過(guò)中斷控制器來(lái)接收和處理外部的中斷信號(hào),而異常模式用于處理內(nèi)部的異常事件。本文將詳細(xì)介紹ARM中斷的原理和實(shí)現(xiàn)方式。 一、ARM
    的頭像 發(fā)表于 01-05 15:18 ?918次閱讀