淺談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/02×03-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虛擬化技術“系列….哈