chinese直男口爆体育生外卖, 99久久er热在这里只有精品99, 又色又爽又黄18禁美女裸身无遮挡, gogogo高清免费观看日本电视,私密按摩师高清版在线,人妻视频毛茸茸,91论坛 兴趣闲谈,欧美 亚洲 精品 8区,国产精品久久久久精品免费

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) ? 來源:Linuxer ? 作者:Linuxer ? 2020-10-09 10:43 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

1: arm smmu的原理

1.1: smmu 基本知識(shí)

如上圖所示,smmu 的作用和mmu 類似,mmu作用是替cpu翻譯頁表將進(jìn)程的虛擬地址轉(zhuǎn)換成cpu可以識(shí)別的物理地址。同理,smmu的作用就是替設(shè)備將dma請(qǐng)求的地址,翻譯成設(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)存中是如何組織的;

對(duì)smmu來說,一個(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來說,我們給他所管理的每個(gè)設(shè)備一個(gè)唯一的device id,這個(gè)device id又叫 stream id;對(duì)于設(shè)備比較少的情況下,我們的smmu 的ste 表,很明顯只需要是1維數(shù)組就可以了,如下圖:

注意,這里ste采用線性表并不是真是由設(shè)備的數(shù)量來決定的,而是寫在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的頁表了,在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的手冊(cè)即可,里面的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表,讀到這里,你是不是會(huì)問一個(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 的話,那咋管理呢?對(duì)不對(duì)?所以smmu 采用了CD表來管理每個(gè)page table;

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

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

CD表,在smmu中也是可以是線性的或者兩級(jí)的,這個(gè)都是在smmu 寄存器中配置好了的,由smmu驅(qū)動(dòng)來讀去,進(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í)開啟stage1 和 stage2的,當(dāng)然了,smmu 也是可以進(jìn)行bypass的;

1.3:smmu的地址翻譯流程

如上圖,基本可以很明顯的概括出了一個(gè)外設(shè)請(qǐng)求 smmu 的地址翻譯的基本流程,當(dāng)一個(gè)外設(shè)需要dma的物理地址的時(shí)候,開始請(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 表,通過這兩個(gè)id smmu 就可以找到對(duì)應(yīng)的iopge table了,smmu找到page table 后結(jié)合外設(shè)提交過來的最后一個(gè)信息iova,即可開始進(jìn)行地址翻譯;

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

上圖中的地址翻譯還涉及到了stage2,這里不解釋了,smmu涉及到虛擬化的過程比較復(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)在來看看在linux內(nèi)核中,smmu驅(qū)動(dòng)是如何完成初始化的過程,借著這個(gè)分析,我們看看smmu里的重要的幾種隊(duì)列:

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

上面是smmu驅(qū)動(dòng)中初始化流程的前半部分,從中可以很容易看出來,內(nèi)核中每個(gè)smmu都有一個(gè)結(jié)構(gòu)體struct arm_smmu_device來管理,實(shí)際上初始化的流程就是在填充著個(gè)結(jié)構(gòu)。看上圖,首先就是從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來從dts或者apci表中讀取smmu的寄存器的基地址,這個(gè)很重要,后續(xù)所有的初始化都是圍繞著個(gè)配置來的;

繼續(xù)看剩下的部分,開頭很容易看出來,要讀取smmu的幾個(gè)中斷號(hào),smmu 硬件給軟件消息有隊(duì)列buffer,smmu硬件通過中斷的方式讓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è)中斷后,開始執(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會(huì)報(bào)告一個(gè)gerror中斷給smmu驅(qū)動(dòng),就不需要隊(duì)列了,因?yàn)楸旧韲?yán)重錯(cuò)誤了,直接中斷上來處理了;

完成了3個(gè)中斷初始化后(具體的中斷初始化映射流程,不在這里介紹,改天單獨(dú)寫個(gè)中斷章節(jié)介紹),smmu 驅(qū)動(dòng)此時(shí)已經(jīng)完成了smmu管理結(jié)構(gòu)的分配,以及smmu配置的讀取,smmu的寄存器的映射,以及smmu中斷的初始化,這些都搞完后,smmu驅(qū)動(dòng)開始讀取提前寫死在 smmu 寄存器中的各種配置,將配置bit位讀取出來放到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的字段里面;

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

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

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

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

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

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

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

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

arm_smmu_init_strtab_2lvl;

我們可以思考一個(gè)問題:我們真的需要將所有的ste entry都個(gè)創(chuàng)造出來嗎?很顯然,不是的,smmu驅(qū)動(dòng)的初始化正是基于這種原理,僅僅只會(huì)初始化第一級(jí)的ste目錄項(xiàng),其實(shí)這里就是類似頁表的初始化了也只是先初始化了目錄項(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)初始化的剩下的,見下圖:

上圖是smmu 驅(qū)動(dòng)初始化的剩下的部分,我們可以看出來里面第一個(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)接下來就是將smmu的基本數(shù)據(jù)結(jié)構(gòu)注冊(cè)到上層的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)不會(huì)都作為一個(gè)獨(dú)立的子系統(tǒng),所以,在linux 內(nèi)核中 抽象了一層 iommu 層,由iommu層給各個(gè)外部設(shè)備驅(qū)動(dòng)提供結(jié)構(gòu),隱藏底層的不同的架構(gòu);如圖所示:

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

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

接下來我們來看看進(jìn)入內(nè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)一管理起來;最后我們根據(jù)smmu所掛載的是pcie外設(shè),還是platform外設(shè),將和個(gè)smmu綁定到不同的總線類型上;

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

iommu 層通過ops來調(diào)用底層硬件驅(qū)動(dòng),我們來看看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),用來代表底層的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, 我們?cè)谡{(diào)用dma alloc的時(shí)候,首先在io 的地址空間中分配你一個(gè)iova, 然后在iommu所管理的頁表中做好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ù)來完成iova和pa的分配與映射;

iommu_dma_alloc->__iommu_dma_alloc_pages,

首先會(huì)調(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的釋放流程也是很簡(jiǎn)單的,首先將iova和pa進(jìn)行解映射處理,然后將iova結(jié)構(gòu)給釋放掉;

看圖中解映射的部分就是在iommu_unmap_fast流程中處理的就是調(diào)用iommu的unmap然后通過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中看看是干啥的,見下圖:

這個(gè)函數(shù)采用遞歸的方式來查找io page table的最后一項(xiàng),當(dāng)找到的時(shí)候,我們可注意看代碼行613~622行,其中613~620行是當(dāng)我們的iommu采用默認(rèn)的non strict模式的時(shí)候,我們是不用立馬對(duì)tlb進(jìn)行無效化的;但是當(dāng)我們采用strict模式的時(shí)候,我們還是會(huì)將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í)候,會(huì)調(diào)用函數(shù)iovad->flush_cb,

這個(gè)函數(shù)指針,最終會(huì)調(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)不會(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的,我們可以通過這個(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;

原文標(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ī)問題,請(qǐng)聯(lián)系本站處理。 舉報(bào)投訴
  • ARM
    ARM
    +關(guān)注

    關(guān)注

    135

    文章

    9582

    瀏覽量

    393464
收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評(píng)論

    相關(guān)推薦
    熱點(diǎn)推薦

    Arm AGI CPU加速新一代基礎(chǔ)設(shè)施建設(shè)

    近期,Arm 推出 Arm AGI CPU,一款由 Arm 自主設(shè)計(jì)、面向人工智能 (AI) 數(shù)據(jù)中心的 CPU,旨在滿足日益增長(zhǎng)的代理式 AI (Agentic AI) 工作負(fù)載需求。這標(biāo)志著
    的頭像 發(fā)表于 04-09 15:55 ?263次閱讀

    Arm攜手Linaro成立開放聯(lián)盟CoreCollective

    如果你是 Arm 軟件生態(tài)的一員,想必對(duì) Linaro 并不陌生。作為一家領(lǐng)先的工程組織,Linaro 自 2010 年成立起,便圍繞 Arm 計(jì)算平臺(tái)構(gòu)建了開放協(xié)作生態(tài)。在過去 15 年間,該生態(tài)
    的頭像 發(fā)表于 03-03 10:13 ?559次閱讀

    Arm SystemReady研討會(huì)圓滿召開

    上周除了有備受矚目的 Arm Unlocked 2025 AI 技術(shù)峰會(huì)之外,Arm SystemReady 研討會(huì)也在深圳熱烈召開。本次會(huì)議吸引了來自芯片供應(yīng)商、操作系統(tǒng)廠商、云服務(wù)提供商、OEM
    的頭像 發(fā)表于 11-11 11:39 ?1041次閱讀

    什么是ARM架構(gòu)?你需要知道的一切

    從智能手機(jī)到工業(yè)邊緣計(jì)算機(jī),ARM?架構(gòu)為全球數(shù)十億臺(tái)設(shè)備提供動(dòng)力。ARM?以其效率優(yōu)先的設(shè)計(jì)和靈活的許可模式而聞名,已迅速?gòu)囊苿?dòng)處理器擴(kuò)展到人工智能邊緣計(jì)算、工業(yè)控制器,甚至數(shù)據(jù)中心。本文我們將
    的頭像 發(fā)表于 09-11 14:48 ?1620次閱讀
    什么是<b class='flag-5'>ARM</b>架構(gòu)?你需要知道的一切

    Arm Zena CSS加速軟件和芯片開發(fā)進(jìn)程

    Arm 控股有限公司(納斯達(dá)克股票代碼:ARM,以下簡(jiǎn)稱 Arm)近期宣布推出 Arm Zena 計(jì)算子系統(tǒng) (Compute Subsystems, CSS)。作為標(biāo)準(zhǔn)化且預(yù)先集成的
    的頭像 發(fā)表于 08-25 16:22 ?2217次閱讀

    一文了解Arm神經(jīng)超級(jí)采樣 (Arm Neural Super Sampling, Arm NSS) 深入探索架構(gòu)、訓(xùn)練和推理

    本文將從訓(xùn)練、網(wǎng)絡(luò)架構(gòu)到后處理和推理等方面,深入探討 Arm 神經(jīng)超級(jí)采樣 (Arm Neural Super Sampling, Arm NSS) 的工作原理,希望為機(jī)器學(xué)習(xí) (ML) 工程師和移動(dòng)端圖形開發(fā)者來詳細(xì)解釋
    的頭像 發(fā)表于 08-14 16:11 ?3237次閱讀

    Arm CEO:公司正在自研芯片

    據(jù)外媒路透社報(bào)道,Arm CEO Rene Haas透露,Arm正在投資開發(fā)自有芯片,并計(jì)劃將部分利潤(rùn)投資于制造自己的芯片和其他組件。與之對(duì)應(yīng)的是Arm預(yù)測(cè)的下一財(cái)季經(jīng)營(yíng)業(yè)績(jī)也會(huì)因?yàn)樽匝行酒鴾p低
    的頭像 發(fā)表于 07-31 11:49 ?758次閱讀

    RISC-V和ARM有何區(qū)別?

    在微處理器架構(gòu)領(lǐng)域,ARM與RISC-V是兩個(gè)備受關(guān)注的體系。ZLG致遠(yuǎn)電子在推出ARM核心版后,又推出了基于RISC-V的MR6450核心版,這引發(fā)了人們對(duì)這兩種架構(gòu)差異的深入探討。ARM
    的頭像 發(fā)表于 06-24 11:38 ?2205次閱讀
    RISC-V和<b class='flag-5'>ARM</b>有何區(qū)別?

    Arm產(chǎn)品命名體系的演變

    Arm 首席執(zhí)行官 Rene Haas 宣布 Arm 推出新的產(chǎn)品命名體系后,本文將為你詳解新的計(jì)算平臺(tái)名稱,以及新命名體系內(nèi)的新 IP 名稱標(biāo)識(shí)。
    的頭像 發(fā)表于 06-19 10:38 ?1084次閱讀
    <b class='flag-5'>Arm</b>產(chǎn)品命名體系的演變

    ARM Mali GPU 深度解讀

    ARM Mali GPU 深度解讀 ARM Mali 是 Arm 公司面向移動(dòng)設(shè)備、嵌入式系統(tǒng)和基礎(chǔ)設(shè)施市場(chǎng)設(shè)計(jì)的圖形處理器(GPU)IP 核,憑借其異構(gòu)計(jì)算架構(gòu)、能效優(yōu)化和生態(tài)協(xié)同,成為全球移動(dòng)
    的頭像 發(fā)表于 05-29 10:12 ?4865次閱讀

    Arm 公司面向 PC 市場(chǎng)的 ?Arm Niva? 深度解讀

    面向 PC 市場(chǎng)的 ? Arm Niva ? 深度解讀 ? Arm Niva ? 是 Arm 公司為 PC 市場(chǎng)推出的核心計(jì)算平臺(tái),屬于其“平臺(tái)優(yōu)先”戰(zhàn)略的關(guān)鍵布局。作為 ? Arm
    的頭像 發(fā)表于 05-29 09:56 ?1843次閱讀

    Arm 公司面向移動(dòng)端市場(chǎng)的 ?Arm Lumex? 深度解讀

    面向移動(dòng)端市場(chǎng)的 ? Arm Lumex ? 深度解讀 ? Arm Lumex ? 是 Arm 公司面向移動(dòng)設(shè)備市場(chǎng)推出的新一代計(jì)算平臺(tái),隸屬于其“平臺(tái)優(yōu)先”戰(zhàn)略的核心布局。作為 ? Arm
    的頭像 發(fā)表于 05-29 09:54 ?4538次閱讀

    Arm 公司面向汽車市場(chǎng)的 ?Arm Zena? 深度解讀

    面向汽車市場(chǎng)的 ? Arm Zena ? 深度解讀 Arm Zena 是 Arm 公司面向智能汽車領(lǐng)域推出的核心計(jì)算平臺(tái),屬于其“平臺(tái)優(yōu)先”戰(zhàn)略的關(guān)鍵布局。作為 Arm 計(jì)算子系統(tǒng)(C
    的頭像 發(fā)表于 05-29 09:51 ?2668次閱讀

    值得體驗(yàn)的多款Windows on Arm應(yīng)用

    隨著越來越多的開發(fā)者紛紛通過 Arm 原生支持的方式,打造更快速、更智能的應(yīng)用體驗(yàn),Windows on Arm 的發(fā)展勢(shì)頭和用戶普及率持續(xù)加速升溫。如今,普通 Windows 用戶有超過 90
    的頭像 發(fā)表于 05-28 13:56 ?2315次閱讀

    Windows Arm64托管運(yùn)行器正式支持GitHub Actions

    過去一年,Arm 與 GitHub 持續(xù)緊密合作,致力于為基于 Arm 平臺(tái)的開發(fā)者打造更便捷、更高效的開發(fā)體驗(yàn)。GitHub 推出的 Arm 托管運(yùn)行器正在革新應(yīng)用程序的開發(fā)與部署流程,而近期推出
    的頭像 發(fā)表于 04-28 14:23 ?1276次閱讀