淺談GPU虛擬化技術(shù)(四)- GPU分片虛擬化

　　讓各位久等了，阿里小二這就開始上新菜：“GPU分片虛擬化”。

　　對于“分片”的理解，相信大家已經(jīng)不陌生了。此處的分片從兩個(gè)維度上來定義：其一，是對GPU在時(shí)間片段上的劃分，與CPU的進(jìn)程調(diào)度類似，一個(gè)物理GPU的計(jì)算engine在幾個(gè)vGPU之間共享，而調(diào)度時(shí)間片一般都在1ms-10ms左右，其二，是對GPU資源的劃分，主要是指對GPU顯存的劃分，以NVIDIA為例，一個(gè)物理GPU帶有16GB的顯存，那么按照16個(gè)vGPU來劃分，每個(gè)vGPU得到1GB的顯存。由于安全隔離的要求，每個(gè)vGPU獨(dú)享分配給它的顯存，不會與其他vGPU共享。

　　技術(shù)上講GPU分片虛擬化，就是指基于VFIO mediated passthrough framework的GPU虛擬化方案。該方案由NVIDIA提出，并聯(lián)合Intel一起提交到了Linux kernel 4.10代碼庫，該方案的kernel部分代碼簡稱mdev模塊。隨后Redhat Enterprise，centos最新的發(fā)行版花了不少力氣又backporting到了3.10.x kernel。所以如果目前采用最新的Redhat 發(fā)行版(企業(yè)版或者centos7.x)等都已經(jīng)自帶mdev模塊。而如果采用ubuntu17.x 以后版本的話，不但自帶mdev功能，連Intel GPU驅(qū)動(i915)也已經(jīng)更新到支持vGPU。無需任何代碼編譯就可以直接體驗(yàn)vGPU虛擬機(jī)功能。

　　那么什么叫mediated passthrough呢? 它與pass through的區(qū)別是什么呢? 一句話解釋：把會影響性能的訪問直接passthrough給虛擬機(jī)，把性能無關(guān)，功能性的MMIO訪問做攔截并在mdev模塊內(nèi)做模擬。太過細(xì)節(jié)的東西詳見后續(xù)篇章。

　　GPU分片虛擬化框架

　　GPU分片虛擬化的方案被NVIDIA與Intel兩家GPU廠家所采用。NVIDIA GRID vGPU系列與Intel的GVT-g(XenGT or KVMGT)。

　　當(dāng)然光有內(nèi)核的支持還不夠，需要加上qemu v2.0 以后版本，加上Intel或者NVIDIA自帶的GPU mdev驅(qū)動(也就是對GPU MMIO訪問的模擬)，那么GPU分片虛擬化的整個(gè)路徑就全了。而GPU廠家的mdev驅(qū)動是否開源取決于自己。按照一貫的作風(fēng)，Intel開源了其絕大部分代碼，包括最新的基于mdev的GPU熱遷移技術(shù)，而NVIDIA也保持其一貫作風(fēng)：不公開。

　　GPU分片虛擬化看起來整個(gè)框架就如下圖一樣(以KVMGT作為例子)：

　　(圖片來源：https://01.org/sites/default/files/documentation/an_introduction_to_intel_GVT-g_for_external.pdf)

　　可以從上圖看到vGPU的模擬是通過kvmGT(Intel)或者NVIDIA-vgpu-vfio(NVIDIA)來完成。該模塊只模擬對MMIO的訪問，也就是功能性，不影響性能的GPU寄存器。而對GPU aperture和GPU graphic memory則通過VFIO的passthrough方式直接映射到VM內(nèi)部。

　　值得注意的是一般Passthrough的方式都依賴IOMMU來完成GPA到HPA的地址轉(zhuǎn)換，而GPU的分片虛擬化完全不依賴IOMMU，也就是說其vGPU的cmd提交(內(nèi)含GPA地址)并不能直接運(yùn)行于GPU硬件之上，至少需要有一個(gè)GPA到HPA的翻譯過程。該過程可以通過host端的cmd掃描來修復(fù)(KVMGT)，NVIDIA GRID vGPU每一個(gè)context有其內(nèi)部page table，會通過修改page table來實(shí)現(xiàn)。

　　由于NVIDIA GRID vGPU代碼閉源，我們將著重介紹Intel的GVT-g方案。

　　Intel GVT-g的介紹

　　說起GVT-g我大概可以講上三天三夜。當(dāng)然大伙這兒也未必想聽。撿簡潔的說起：

　　Kernel 與 mdev驅(qū)動源碼：

　　https://github.com/intel/GVT-linux

　　qemu：

　　https://github.com/intel/IGVTg-qemu

　　setup文檔：

　　https://github.com/intel/GVT-linux/wiki/GVTg_Setup_Guide

　　我們可以在任何一個(gè)帶集成顯卡Intel SKL/BDW的機(jī)器上運(yùn)行GVT-g虛擬化的方案。GVT-g的GPU虛擬化方案也被用到了嵌入式，車載系統(tǒng)等領(lǐng)域(ARCN hypervisor)。

　　干貨來了J 對于想了解GPU的運(yùn)作，以及軟硬件規(guī)范的，Intel其實(shí)已經(jīng)開源了其大部分標(biāo)準(zhǔn)。

　　https://01.org/linuxgraphics/documentation/hardware-specification-prms

　　截個(gè)屏，對于想了解GPU內(nèi)部部分設(shè)計(jì)與運(yùn)行機(jī)制的人來說，光看看這個(gè)列表就會莫名的興奮。

　　GVT-g由于是基于Intel的集成顯卡，所以對運(yùn)行環(huán)境的硬件要求非常低。任何Intel的帶GPU的ATOM，Mobile Core或者Xeon E3等等CPU都能支持vGPU虛擬化(HSW，BDW，SKL系列CPU)。

　　又同時(shí)GVT-g完全免費(fèi)，用戶不需要花費(fèi)額外的費(fèi)用來支持vGPU的應(yīng)用。

　　也正是這些優(yōu)點(diǎn)，使得GVT-g可以被廣泛的運(yùn)用到任何對終端有虛擬化與顯示要求的場景。比如XenClient，比如ARCN等等。

　　GVT-g的優(yōu)點(diǎn)之一在于對其本地顯示的良好支持。

　　GVT-g在內(nèi)部虛擬了一個(gè)類似display pipeline的組件，來接管GPU display port上連接的顯示器。所以vGPU內(nèi)部framebuffer的信息可以被GVT-g快速的顯示在物理GPU連接的顯示器上。其顯示FPS可以到達(dá)驚人的60FPS。完全達(dá)到了物理顯示器的效果。更為強(qiáng)悍的是，vGPU通過對這些port和EDID的模擬可以在虛擬機(jī)內(nèi)部支持多屏顯示，其顯示效果達(dá)到了完全與物理機(jī)狀態(tài)下難分難解的地步。

　　其framebuffer的傳輸路徑可謂九曲十八彎…但效果還不錯(cuò)。60fps妥妥的。

　　內(nèi)嵌一段視頻，來描述兩個(gè)VM是如何共享同一個(gè)物理顯示器，并能做到流暢切換：

　　https://01.org/sites/default/files/downloads/iGVT-g/iGVT-g-demokvmgt.zip

　　GVT-g的Media transcoding能力

　　Intel GPU對media decoding/encoding的硬件支持是其一大特色。GVT-g在vGPU虛擬化的過程中也加入了對media decoding/encoding的支持。其虛擬化后的vGPU的編解碼吞吐能力可以達(dá)到驚人的99%物理GPU的吞吐量(HSW GPU 2014年)。仗著當(dāng)年vGPU media transcoding 99%物理性能的優(yōu)勢，GVT-g團(tuán)隊(duì)在當(dāng)年深圳舉行的IDF上提出了Intel GVT-g對media cloud的未來設(shè)想。并在2015的巴塞羅那世界移動大會上聯(lián)合華為做了一個(gè)GVT-g對Media Cloud的展臺。其架構(gòu)設(shè)想如下圖(圖中綠色方塊為Media Cloud的發(fā)力點(diǎn)，截圖來自GVTg官網(wǎng))

　　https://01.org/sites/default/files/documentation/intel_graphics_virtualization_for_media_cloud.pdf

　　隨后由于Intel GPU軟硬件設(shè)計(jì)人員在下一代GPU中的設(shè)計(jì)沒有全面考慮分片虛擬化場景，在一定程度上破壞了GVT-g在media transcoding上面的優(yōu)勢。目前在BDW和SKL上面的vGPU編解碼效率已經(jīng)不盡人意，失去了其優(yōu)勢。

　　不得不感嘆一下，曾夢想仗劍走天涯….如今已涼涼

　　GVT-g技術(shù)的渲染能力

　　直接從Intel GVT的官網(wǎng)摳數(shù)據(jù)(https://01.org/sites/default/files/documentation/an_introduction_to_intel_GVT-g_for_external.pdf)

　　vGPU基本上對于Graphic rendering的能力是物理GPU的80%以上，一般在90%左右，回憶一下我們在第三章中介紹的AMD的SRIOV類型GPU虛擬化下vGPU的渲染能力可以達(dá)到97%左右。同時(shí)本身Intel GPU物理渲染能力與AMD/NVIDIA的同時(shí)代GPU比較也遠(yuǎn)遠(yuǎn)處于下風(fēng)。所以對于強(qiáng)調(diào)大計(jì)算力的3D渲染場景的vGPU應(yīng)用，Intel GPU的應(yīng)用比較受限。

　　從技術(shù)的角度來看，GVT-g對于vGPU的性能損耗主要開銷在于對其中斷相關(guān)MMIO的模擬。比如對于AMD的SRIOV方案，其VM中對vGPU的MMIO訪問完全沒有虛擬化開銷，不會有trap發(fā)生。即便不采用SRIOV方案，一般來說，硬件設(shè)計(jì)很多時(shí)候會考慮到對虛擬化的要求，并做出有利于虛擬化框架的改動。類似這種中斷相關(guān)對性能敏感的MMIO是需要特殊設(shè)計(jì)以減少在虛擬化下的損耗。而像Intel GPU這樣完全不考慮虛擬化開銷的硬件設(shè)計(jì)，使得GVT-g在軟件層面無論如何優(yōu)化都無法達(dá)到潛在對手的高度。為什么說是潛在對手呢?因?yàn)閷τ贜VIDIA來說，GVT-g與Intel GPU根本就算不上是一個(gè)對手。

　　GVT-g的GPGPU能力

　　GVT-g vGPU只做到了可以運(yùn)行OpenCL，而對performance等并沒有做任何優(yōu)化。Intel GPU硬件在computing和深度學(xué)習(xí)方面本就不是強(qiáng)項(xiàng)。

　　GVT-g的Live Migration

　　GVT-g的vGPU在軟件層次做到了極致。其早在2015年末就開始了對vGPU的熱遷移支持。并在2016年對外公布。而GRID vGPU只在最近才有消息透露其在Citrix的某些產(chǎn)品上支持vGPU的熱遷移，并只支持部分GPU型號。而AMD的SRIOV方案至今沒有熱遷移方面的公開消息。

　　vGPU的熱遷移細(xì)節(jié)太過技術(shù)化，此處不多做介紹，但是當(dāng)年第一個(gè)支持vGPU的VM渲染實(shí)時(shí)遷移的效果還是讓人印象深刻的。其視頻是基于KVM的vGPU遷移過程。

　　從視頻截圖中可以看出，其所有遷移過程在小于1秒的時(shí)間內(nèi)完成并顯示在新機(jī)器上了。(Demo的實(shí)際整體遷移時(shí)間為300ms左右)

　　https://www.youtube.com/watch?v=y2SkU5JODIY

　　GVT-g的調(diào)度

　　實(shí)話說GVT-g的調(diào)度并沒有AMD SRIOV vGPU做的好。其調(diào)度粒度雖然是在1ms時(shí)間片的維度上做調(diào)度和vGPU切換。但是由于GPU軟硬件對preempt功能的支持尚未完備，實(shí)際調(diào)度往往需要等當(dāng)前vGPU的任務(wù)結(jié)束才能開始。在渲染大幀的情況下vGPU調(diào)度信息一般的統(tǒng)計(jì)顯示，其基本上在5-10ms左右的間隔做vGPU切換。回憶一下AMD的SRIOV是嚴(yán)格6ms一次。而NVIDIA的GRID vGPU有多種調(diào)度策略，由于閉源，沒有更多的信息可以拿到其調(diào)度信息。有心得讀者可以在虛擬機(jī)下通過rebuild NVIDIA Guest Linux驅(qū)動研究一下。

　　GVT-g的局限性

　　當(dāng)然悲催的是，也正是由于GVT-g是基于Intel的集成顯卡，即便是免費(fèi)附加增值服務(wù)，GVT-g在數(shù)據(jù)中心也很少被采用。第一本身的GPU性能無法與AMD/NVIDIA同類產(chǎn)品競爭，第二數(shù)據(jù)中心追求的是高密度運(yùn)用，集成顯卡無論如何都無法做到一機(jī)多卡的情況，在機(jī)房機(jī)架，寸土寸金的地方，大家都會考慮成本。Intel也作過一些嘗試，把幾個(gè)Xeon E3的CPU做到一塊PCIE板卡上面增加其計(jì)算密度，然而其功耗和售價(jià)都無法與其他對手競爭。同時(shí)這種設(shè)計(jì)也使得軟件系統(tǒng)復(fù)雜難維護(hù)。

　　NVIDIA GRID vGPU的介紹

　　閉源系統(tǒng)，沒什么好介紹的。值得一提的是NVIDIA GRID vGPU是正式商用的方案。其技術(shù)在VMWare，XenServer，Redhat等大廠已經(jīng)久經(jīng)考驗(yàn)。

　　GRID vGPU在VDI上的運(yùn)用

　　GRID vGPU在VDI的運(yùn)用要早于GVT-g和AMD的SRIOV。早期GRID已經(jīng)與VMWare合作堆出了一些列remote display的方案。GRID vGPU擅長remote display，GVT-g擅長local display，各有優(yōu)點(diǎn)。

　　GRID vGPU渲染能力

　　對比GVT-g，GRID vGPU在圖形渲染方面的虛擬化損耗非常小幾乎與AMD SRIOV的類似，可以達(dá)到其passthrough狀態(tài)下的99%左右。而GVT-g卻在90%左右。

　　GRID vGPU通用計(jì)算能力

　　雖然沒有多少人會在一個(gè)分片GPU虛擬化的VM內(nèi)部作深度學(xué)習(xí)計(jì)算，但GRID vGPU的計(jì)算性能也已經(jīng)可以達(dá)到其passthrough狀態(tài)下的80%以上。其目前vGPU 1：1分片(一個(gè)物理GPU只分一個(gè)vGPU)情況下，各項(xiàng)性能指標(biāo)幾乎已經(jīng)與passthrough GPU的方案不相上下。完全可以取代GPU passthrough的方案。但對多vGPU的支持，目前GRID vGPU無法支持。這是其對比GPU passthrough方案最大的弊端。NVIDIA顯然不會坐視不理，GRID vGPU將來一定會考慮多vGPU的場景并支持P2P。GRID vGPU另外一個(gè)對比passthrough GPU的好處就是可以在Host端對vGPU關(guān)鍵性能指標(biāo)的監(jiān)控。還記得我們在本系列第二章介紹GPU passthrough方案的時(shí)候提到的：GPU passthrough方法的固有缺點(diǎn)嗎?GPU passthrough情況下host端對vGPU無法進(jìn)行有效監(jiān)控，而這在GRID vGPU的場景下完全不成問題。

　　GRID vGPU分片虛擬化的方案相對GPU passthrough來說部署比較困難，由于閉源，其并不像Intel GVT-g一樣一切開源并整合到kernel代碼庫中，一般廠商需要使用該技術(shù)還得作不同程度的kernel適配和調(diào)試。發(fā)布周期至少半年以上。

　　各個(gè)GPU虛擬化方案的一些實(shí)現(xiàn)細(xì)節(jié)異同

　　Mediated passthrough (mdev)

　　我們再次來回顧一下什么叫mediated passthrough。首先應(yīng)該查看kernel document:

　　https://github.com/torvalds/linux/blob/master/Documentation/vfio-mediated-device.txt

　　之前已經(jīng)提到Mediated是指對MMIO 訪問的攔截和emulation，對DMA transfer的提交作GFN到PFN的地址轉(zhuǎn)換。

　　NVIDIA在2016年的KVM forum上面已經(jīng)很詳細(xì)的介紹了這些細(xì)節(jié)。

　　http://www.linux-kvm.org/images/5/59/02x03-Neo_Jia_and_Kirti_Wankhede-vGPU_on_KVM-A_VFIO_based_Framework.pdf

　　GPU command的提交方式

　　三個(gè)GPU虛擬化的方案在GPU command(batch buffer)的提交方式上是由本質(zhì)區(qū)別的。GVT-g與GRID vGPU作為分片虛擬化的代表，其任何vGPU的cmd提交都會被攔截到host端作emulation。并通過host的處理以后由host代替vGPU提交到物理GPU。AMD SRIOV方案其本質(zhì)上也是一種GPU分片虛擬化，并且其與mdev的區(qū)別就是分片方式是：通過SRIOV的標(biāo)準(zhǔn)還是通過mdev軟件方式實(shí)施，而對SRIOV vGPU的emulation則在Host端的GPU硬件，F(xiàn)irmware，GIM驅(qū)動共同完成。

　　而GPU passthrough方式下，vGPU的cmd直接由虛擬機(jī)內(nèi)部提交。無需再繞道Host端。由此 passthrough下，無法對虛擬機(jī)內(nèi)部vGPU的運(yùn)作做出監(jiān)控。

　　簡單點(diǎn)講：GVT-g與GRID vGPU的提交方式為一類，SRIOV與GPU passthrough方式為另一類。

　　IOMMU

　　分片虛擬化不需要IOMMU硬件的支持。其只需要VFIO模塊添加type1 IOMMU的驅(qū)動，來通知host將要進(jìn)行的DMA傳輸?shù)腉FN，VA等信息，并在Host端的mdev設(shè)備驅(qū)動層完成GFN到PFN的翻譯處理。可以理解為軟件層面上的IOMMU操作。

　　而AMD SRIOV與GPU passthrough方式下，IOMMU是必備組件。尤其IOMMU硬件完成GFN到PFN的地址轉(zhuǎn)換。

　　簡而言之，GVT-g，GRID vGPU是一伙，SRIOV，GPU passthrough是一伙。

　　至此，“淺談GPU虛擬化技術(shù)“系列文章完結(jié)。謝謝大家拜讀。盡情等待未來“深入GPU虛擬化技術(shù)“系列….哈

　　作者：鄭曉，龍欣，彈性計(jì)算異構(gòu)計(jì)算項(xiàng)目組

　　本系列上篇文章：http://cloud.it168.com/a2018/0520/3204/000003204070.shtml

　　欲了解更多內(nèi)容，請關(guān)注鄭曉老師個(gè)人博客。