作者：鄭曉，龍欣，彈性計算異構計算項目組
讓各位久等了，阿裡小二這就開始上新菜：“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-linuxqemu：
https://github.com/intel/IGVTg-qemusetup文檔：
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.zipGVT-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官網）
随後由于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左右）
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.pdfGPU 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虛拟化技術“系列….哈