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

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

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

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

　　那么什么叫mediated passthrough呢? 它與pass through的區別是什么呢? 一句話解釋：把會影響性能的訪問直接passthrough給虛擬機，把性能無關，功能性的MMIO訪問做攔截并在mdev模塊內做模擬。太過細節的東西詳見后續篇章。

　　GPU分片虛擬化框架

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

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

　　GPU分片虛擬化看起來整個框架就如下圖一樣(以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內部。

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

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

　　Intel GVT-g的介紹

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

　　Kernel 與 mdev驅動源碼：

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

　　qemu：

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

　　setup文檔：

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

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

　　干貨來了J 對于想了解GPU的運作，以及軟硬件規范的，Intel其實已經開源了其大部分標準。

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

　　截個屏，對于想了解GPU內部部分設計與運行機制的人來說，光看看這個列表就會莫名的興奮。

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

　　又同時GVT-g完全免費，用戶不需要花費額外的費用來支持vGPU的應用。

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

　　GVT-g的優點之一在于對其本地顯示的良好支持。

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

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

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

　　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的編解碼吞吐能力可以達到驚人的99%物理GPU的吞吐量(HSW GPU 2014年)。仗著當年vGPU media transcoding 99%物理性能的優勢，GVT-g團隊在當年深圳舉行的IDF上提出了Intel GVT-g對media cloud的未來設想。并在2015的巴塞羅那世界移動大會上聯合華為做了一個GVT-g對Media Cloud的展臺。其架構設想如下圖(圖中綠色方塊為Media Cloud的發力點，截圖來自GVTg官網)

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

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

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

　　GVT-g技術的渲染能力

　　直接從Intel GVT的官網摳數據(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的渲染能力可以達到97%左右。同時本身Intel GPU物理渲染能力與AMD/NVIDIA的同時代GPU比較也遠遠處于下風。所以對于強調大計算力的3D渲染場景的vGPU應用，Intel GPU的應用比較受限。

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

　　GVT-g的GPGPU能力

　　GVT-g vGPU只做到了可以運行OpenCL，而對performance等并沒有做任何優化。Intel GPU硬件在computing和深度學習方面本就不是強項。

　　GVT-g的Live Migration

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

　　vGPU的熱遷移細節太過技術化，此處不多做介紹，但是當年第一個支持vGPU的VM渲染實時遷移的效果還是讓人印象深刻的。其視頻是基于KVM的vGPU遷移過程。

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

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

　　GVT-g的調度

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

　　GVT-g的局限性

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

　　NVIDIA GRID vGPU的介紹

　　閉源系統，沒什么好介紹的。值得一提的是NVIDIA GRID vGPU是正式商用的方案。其技術在VMWare，XenServer，Redhat等大廠已經久經考驗。

　　GRID vGPU在VDI上的運用

　　GRID vGPU在VDI的運用要早于GVT-g和AMD的SRIOV。早期GRID已經與VMWare合作堆出了一些列remote display的方案。GRID vGPU擅長remote display，GVT-g擅長local display，各有優點。

　　GRID vGPU渲染能力

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

　　GRID vGPU通用計算能力

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

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

　　各個GPU虛擬化方案的一些實現細節異同

　　Mediated passthrough (mdev)

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

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

　　之前已經提到Mediated是指對MMIO 訪問的攔截和emulation，對DMA transfer的提交作GFN到PFN的地址轉換。

　　NVIDIA在2016年的KVM forum上面已經很詳細的介紹了這些細節。

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

　　GPU command的提交方式

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

　　而GPU passthrough方式下，vGPU的cmd直接由虛擬機內部提交。無需再繞道Host端。由此 passthrough下，無法對虛擬機內部vGPU的運作做出監控。

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

　　IOMMU

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

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

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

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

　　作者：鄭曉，龍欣，彈性計算異構計算項目組

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

　　欲了解更多內容，請關注鄭曉老師個人博客。