一文講解Linux虛擬化KVM-Qemu分析之virtio初探
說(shuō)明：
KVM版本：5.9.1
QEMU版本：5.0.0
工具：Source Insight 3.5， Visio
概述
從本文開(kāi)始將研究一下virtio；
本文會(huì)從一個(gè)網(wǎng)卡虛擬化的例子來(lái)引入virtio，并從大體架構(gòu)上進(jìn)行介紹，有個(gè)宏觀的認(rèn)識(shí)；
細(xì)節(jié)的闡述后續(xù)的文章再跟進(jìn)；
1. 網(wǎng)卡
1.1 網(wǎng)卡工作原理
先來(lái)看一下網(wǎng)卡的架構(gòu)圖（以Intel的82540為例）：
OSI模型，將網(wǎng)絡(luò)通信中的數(shù)據(jù)流劃分為7層，最底下兩層為物理層和數(shù)據(jù)鏈路層，對(duì)應(yīng)到網(wǎng)卡上就是
PHY和MAC控制器；PHY：對(duì)應(yīng)物理層，負(fù)責(zé)通信設(shè)備與網(wǎng)絡(luò)媒介（網(wǎng)線）之間的互通，它定義傳輸?shù)墓怆娦盘?hào)、線路狀態(tài)等；MAC控制器：對(duì)應(yīng)數(shù)據(jù)鏈路層，負(fù)責(zé)網(wǎng)絡(luò)尋址、錯(cuò)誤偵測(cè)和改錯(cuò)等；PHY和MAC通過(guò)MII/GMII(Media Independent Interface)和MDIO(Management Data Input/output)相連；MII/GMII(Gigabit MII)：由IEEE定義的以太網(wǎng)行業(yè)標(biāo)準(zhǔn)，與媒介無(wú)關(guān)，包含數(shù)據(jù)接口和管理接口，用于網(wǎng)絡(luò)數(shù)據(jù)傳輸；MDIO接口，也是由IEEE定義，一種簡(jiǎn)單的串行接口，通常用于控制收發(fā)器，并收集狀態(tài)信息等；網(wǎng)卡通過(guò)PCI接口接入到PCI總線中，CPU可以通過(guò)訪問(wèn)BAR空間來(lái)獲取數(shù)據(jù)包，也有網(wǎng)卡直接掛在內(nèi)存總線上；
網(wǎng)卡還有一顆EEPROM芯片，用于記錄廠商ID、網(wǎng)卡的MAC地址、配置信息等；
我們主要關(guān)心它的數(shù)據(jù)流，所以，看看它的工作原理吧：
網(wǎng)絡(luò)包的接收與發(fā)送，都是典型的
生產(chǎn)者-消費(fèi)者模型，簡(jiǎn)單來(lái)說(shuō)，CPU會(huì)在內(nèi)存中維護(hù)兩個(gè)ring-buffer，分別代表RX和TX，ring-buffer中存放的是描述符，描述符里包含了一個(gè)網(wǎng)絡(luò)包的信息，包括了網(wǎng)絡(luò)包地址、長(zhǎng)度、狀態(tài)等信息；ring-buffer有頭尾兩個(gè)指針，發(fā)送端為：TDH(Transmit Descriptor Head)和TDT(Transmit Descriptor Tail)，同理，接收端為：RDH(Receive Descriptor Head)和RDT(Receive Descriptor Tail)，在數(shù)據(jù)傳輸時(shí)，由CPU和網(wǎng)卡來(lái)分開(kāi)更新頭尾指針的值，這也就是生產(chǎn)者更新尾指針，消費(fèi)者更新頭指針，永遠(yuǎn)都是消費(fèi)者追著生產(chǎn)者跑，ring-buffer也就能轉(zhuǎn)起來(lái)了；數(shù)據(jù)的傳輸，使用DMA來(lái)進(jìn)行搬運(yùn)，CPU的拷貝顯然是一種低效的選擇。在之前PCI系列分析文章中分析過(guò)，PCI設(shè)備有自己的BAR空間，可以通過(guò)DMA在BAR空間和DDR空間內(nèi)進(jìn)行搬運(yùn)；
【文章福利】小編推薦自己的Linux內(nèi)核技術(shù)交流群:【749907784】整理了一些個(gè)人覺(jué)得比較好的學(xué)習(xí)書(shū)籍、視頻資料共享在群文件里面，有需要的可以自行添加哦?。。。ê曨l教程、電子書(shū)、實(shí)戰(zhàn)項(xiàng)目及代碼)?
1.2 Linux網(wǎng)卡驅(qū)動(dòng)
在網(wǎng)卡數(shù)據(jù)流圖中，我們也基本看到了網(wǎng)卡驅(qū)動(dòng)的影子，驅(qū)動(dòng)與網(wǎng)卡之間是異步通信：
驅(qū)動(dòng)程序負(fù)責(zé)硬件的初始化，以及TX和RX的
ring-buffer的創(chuàng)建及初始化；ndo_start_xmit負(fù)責(zé)將網(wǎng)絡(luò)包通過(guò)驅(qū)動(dòng)程序發(fā)送出去，netif_receive_skb負(fù)責(zé)通過(guò)驅(qū)動(dòng)程序接收網(wǎng)絡(luò)包數(shù)據(jù)；數(shù)據(jù)通過(guò)
struct sk_buff來(lái)存儲(chǔ)；發(fā)送數(shù)據(jù)時(shí)，CPU負(fù)責(zé)準(zhǔn)備TX網(wǎng)絡(luò)包數(shù)據(jù)以及描述符資源，更新TDT指針，并通知NIC可以進(jìn)行數(shù)據(jù)發(fā)送了，當(dāng)數(shù)據(jù)發(fā)送完畢后NIC通過(guò)中斷信號(hào)通知CPU進(jìn)行下一個(gè)包的處理；
接收數(shù)據(jù)時(shí)，CPU負(fù)責(zé)準(zhǔn)備RX的描述符資源，接收數(shù)據(jù)后，NIC通過(guò)中斷通知CPU，驅(qū)動(dòng)程序通過(guò)調(diào)度內(nèi)核線程來(lái)處理網(wǎng)絡(luò)包數(shù)據(jù)，處理完成后進(jìn)行下一包的接收；
2. 網(wǎng)卡全虛擬化
2.1 全虛擬化方案
全虛擬化方案，通過(guò)軟件來(lái)模擬網(wǎng)卡，Qemu+KVM的方案如下圖：
Qemu中，設(shè)備的模擬稱為前端，比如
e1000，前端與后端通信，后端再與底層通信，我們來(lái)分別看看發(fā)送和接收處理的流程；
?
發(fā)送：
Guest OS在準(zhǔn)備好網(wǎng)絡(luò)包數(shù)據(jù)以及描述符資源后，通過(guò)寫
TDT寄存器，觸發(fā)VM的異常退出，由KVM模塊接管；KVM模塊返回到Qemu后，Qemu會(huì)檢查VM退出的原因，比如檢查到
e1000寄存器訪問(wèn)出錯(cuò)，因而觸發(fā)e1000前端工作；Qemu能訪問(wèn)Guest OS中的地址內(nèi)容，因而
e1000前端能獲取到Guest OS內(nèi)存中的網(wǎng)絡(luò)包數(shù)據(jù)，發(fā)送給后端，后端再將網(wǎng)絡(luò)包數(shù)據(jù)發(fā)送給TUN/TAP驅(qū)動(dòng)，其中TUN/TAP為虛擬網(wǎng)絡(luò)設(shè)備；數(shù)據(jù)發(fā)送完成后，除了更新
ring-buffer的指針及描述符狀態(tài)信息外，KVM模塊會(huì)模擬TX中斷；當(dāng)再次進(jìn)入VM時(shí)，Guest OS看到的是數(shù)據(jù)已經(jīng)發(fā)送完畢，同時(shí)還需要進(jìn)行中斷處理；
Guest OS跑在vCPU線程中，發(fā)送數(shù)據(jù)時(shí)相當(dāng)于會(huì)打算它的執(zhí)行，直到處理完后再恢復(fù)回來(lái)，也就是一個(gè)嚴(yán)格的同步處理過(guò)程；
接收：
當(dāng)TUN/TAP有網(wǎng)絡(luò)包數(shù)據(jù)時(shí)，可以通過(guò)讀取TAP文件描述符來(lái)獲取；
Qemu中的I/O線程會(huì)被喚醒并觸發(fā)后端處理，并將數(shù)據(jù)發(fā)送給
e1000前端；e1000前端將數(shù)據(jù)拷貝到Guest OS的物理內(nèi)存中，并模擬RX中斷，觸發(fā)VM的退出，并由KVM模塊接管；KVM模塊返回到Qemu中進(jìn)行處理后，并最終重新進(jìn)入Guest OS的執(zhí)行中斷處理；
由于有I/O線程來(lái)處理接收，能與vCPU線程做到并行處理，這一點(diǎn)與發(fā)送不太一樣；
2.2 弊端
Guest OS去操作寄存器的時(shí)候，會(huì)觸發(fā)VM退出，涉及到KVM和Qemu的處理，并最終再次進(jìn)入VM，overhead較大；
不管是在Host還是Guest中，中斷處理的開(kāi)銷也很大，中斷涉及的寄存器訪問(wèn)也較多；
軟件模擬的方案，吞吐量性能也比較低，時(shí)延較大；
所以，讓我們大聲喊出本文的主角吧！
3. 網(wǎng)卡半虛擬化
在進(jìn)入主題前，先思考幾個(gè)問(wèn)題：
全虛擬化下Guest可以重用驅(qū)動(dòng)、網(wǎng)絡(luò)協(xié)議棧等，但是在軟件全模擬的情況下，我們是否真的需要去訪問(wèn)寄存器嗎（比如中斷處理），真的需要模擬網(wǎng)卡的自協(xié)商機(jī)制以及EEPROM等功能嗎？
是否真的需要模擬大量的硬件控制寄存器，而這些寄存器在軟件看來(lái)毫無(wú)意義？
是否真的需要生產(chǎn)者/消費(fèi)者模型的通知機(jī)制（寄存器訪問(wèn)、中斷）？
3.1 virtio
網(wǎng)卡的工作過(guò)程是一個(gè)生產(chǎn)者消費(fèi)者模型，但是在前文中可以看出，在全虛擬化狀態(tài)下存在一些弊端，一個(gè)更好的生產(chǎn)者消費(fèi)者模型應(yīng)該遵循以下原則：
寄存器只被生產(chǎn)者使用去通知消費(fèi)者
ring-buffer有數(shù)據(jù)（消費(fèi)者可以繼續(xù)消費(fèi)），而不再被用作存儲(chǔ)狀態(tài)信息；中斷被消費(fèi)者用來(lái)通知生產(chǎn)者
ring-buffer是非滿狀態(tài)（生產(chǎn)者可以繼續(xù)生產(chǎn)）；生產(chǎn)者和消費(fèi)者的狀態(tài)信息應(yīng)該存儲(chǔ)在內(nèi)存中，這樣讀取狀態(tài)信息時(shí)不需要VM退出，減少overhead；
生產(chǎn)者和消費(fèi)者跑在不同的線程中，可以并行運(yùn)行，并且盡可能多的處理任務(wù)；
非必要情況下，相互之間的通知應(yīng)該避免使用；
忙等待（比如輪詢）不是一個(gè)可以接受的通用解決方案；
基于上述原則，我們來(lái)看看從特殊到一般的過(guò)程：
第一行是針對(duì)網(wǎng)卡的實(shí)現(xiàn)，第二行更進(jìn)一步的抽象，第三行是通用的解決方案了，對(duì)I/O操作的虛擬化通用支持；
所以，在virtio的方案下，網(wǎng)卡的虛擬化看上去就是下邊這個(gè)樣子了：
Hypervisor和Guest都需要實(shí)現(xiàn)virtio，這也就意味著Guest的設(shè)備驅(qū)動(dòng)知道自己本身運(yùn)行在VM中；
virtio的目標(biāo)是高性能的設(shè)備虛擬化，已經(jīng)形成了規(guī)范來(lái)定義標(biāo)準(zhǔn)的消息傳遞API，用于驅(qū)動(dòng)和Hypervisor之間的傳遞，不同的驅(qū)動(dòng)和前端可以使用相同的API；
virtio驅(qū)動(dòng)（比如圖中的virtio-net driver）的工作是將OS-specific的消息轉(zhuǎn)換成virtio格式的消息，而對(duì)端（virtio-net frontend）則是做相反的工作；
virtio的數(shù)據(jù)傳遞使用scatter-gather list（sg-list）：
sg-list是概念上的（物理）地址和長(zhǎng)度對(duì)的鏈表，通常作為數(shù)組來(lái)實(shí)現(xiàn)；
每個(gè)sg-list描述一個(gè)多塊的buffer，消費(fèi)者用它來(lái)作為輸入或輸出操作；
? virtio的核心是virtqueue(VQ)的抽象：
VQ是隊(duì)列，sg-list會(huì)被Guest的驅(qū)動(dòng)放置到VQ中，以供Hypervisor來(lái)消費(fèi)；
輸出sg-list用于向Hypervisor來(lái)發(fā)送數(shù)據(jù)，而輸入sg-list用于接收Hypervisor的數(shù)據(jù)；
驅(qū)動(dòng)可以使用一個(gè)或多個(gè)
virqueue；
當(dāng)Guest的驅(qū)動(dòng)產(chǎn)生一個(gè)sg-list時(shí)，調(diào)用
add_buf(SG, Token)入列；Hypervisor進(jìn)行出列操作，并消費(fèi)sg-list，并將sg-list push回去；
Guest通過(guò)
get_buf()進(jìn)行清理工作；
上圖說(shuō)的是數(shù)據(jù)流方向，那么事件的通知機(jī)制如下：
當(dāng)Guest驅(qū)動(dòng)想要Hypervisor消費(fèi)sg-list時(shí)，通過(guò)VQ的
kick來(lái)進(jìn)行通知；當(dāng)Hypervisor通知Guest驅(qū)動(dòng)已經(jīng)消費(fèi)完了，通過(guò)
interupt來(lái)進(jìn)行通知；
大體的數(shù)據(jù)流和控制流講完了，細(xì)節(jié)實(shí)現(xiàn)后續(xù)再跟進(jìn)了。
3.2 半虛擬化方案
那么，半虛擬化框架下的網(wǎng)卡虛擬化數(shù)據(jù)流是啥樣的呢？
發(fā)送
接收
相信你應(yīng)該對(duì)virtio有個(gè)大概的了解了，好了，收工。
原文作者：LoyenWang
