背景

• Read the fucking source code! --By 魯迅
• A picture is worth a thousand words. --By 高爾基

說明：

1. KVM版本：5.9.1
2. QEMU版本：5.0.0
3. 工具：Source Insight 3.5， Visio

概述

• 從本文開始將研究一下virtio；
• 本文會(huì)從一個(gè)網(wǎng)卡虛擬化的例子來引入virtio，并從大體架構(gòu)上進(jìn)行介紹，有個(gè)宏觀的認(rèn)識；
• 細(xì)節(jié)的闡述后續(xù)的文章再跟進(jìn)；

1. 網(wǎng)卡

1.1 網(wǎng)卡工作原理

先來看一下網(wǎng)卡的架構(gòu)圖（以Intel的82540為例）：

• OSI模型，將網(wǎng)絡(luò)通信中的數(shù)據(jù)流劃分為7層，最底下兩層為物理層和數(shù)據(jù)鏈路層，對應(yīng)到網(wǎng)卡上就是PHY和MAC控制器；
• PHY：對應(yīng)物理層，負(fù)責(zé)通信設(shè)備與網(wǎng)絡(luò)媒介（網(wǎng)線）之間的互通，它定義傳輸?shù)墓怆娦盘?、線路狀態(tài)等；
• MAC控制器：對應(yīng)數(shù)據(jù)鏈路層，負(fù)責(zé)網(wǎng)絡(luò)尋址、錯(cuò)誤偵測和改錯(cuò)等；
• PHY和MAC通過MII/GMII(Media Independent Interface)和MDIO(Management Data Input/output)相連；
• MII/GMII(Gigabit MII)：由IEEE定義的以太網(wǎng)行業(yè)標(biāo)準(zhǔn)，與媒介無關(guān)，包含數(shù)據(jù)接口和管理接口，用于網(wǎng)絡(luò)數(shù)據(jù)傳輸；
• MDIO接口，也是由IEEE定義，一種簡單的串行接口，通常用于控制收發(fā)器，并收集狀態(tài)信息等；
• 網(wǎng)卡通過PCI接口接入到PCI總線中，CPU可以通過訪問BAR空間來獲取數(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)者模型，簡單來說，CPU會(huì)在內(nèi)存中維護(hù)兩個(gè)ring-buffer，分別代表RX和TX，ring-buffer中存放的是描述符，描述符里包含了一個(gè)網(wǎng)絡(luò)包的信息，包括了網(wǎng)絡(luò)包地址、長度、狀態(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)卡來分開更新頭尾指針的值，這也就是生產(chǎn)者更新尾指針，消費(fèi)者更新頭指針，永遠(yuǎn)都是消費(fèi)者追著生產(chǎn)者跑，ring-buffer也就能轉(zhuǎn)起來了；
• 數(shù)據(jù)的傳輸，使用DMA來進(jìn)行搬運(yùn)，CPU的拷貝顯然是一種低效的選擇。在之前PCI系列分析文章中分析過，PCI設(shè)備有自己的BAR空間，可以通過DMA在BAR空間和DDR空間內(nèi)進(jìn)行搬運(yùn)；

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ò)包通過驅(qū)動(dòng)程序發(fā)送出去，netif_receive_skb負(fù)責(zé)通過驅(qū)動(dòng)程序接收網(wǎng)絡(luò)包數(shù)據(jù)；
• 數(shù)據(jù)通過struct sk_buff來存儲(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通過中斷信號通知CPU進(jìn)行下一個(gè)包的處理；
• 接收數(shù)據(jù)時(shí)，CPU負(fù)責(zé)準(zhǔn)備RX的描述符資源，接收數(shù)據(jù)后，NIC通過中斷通知CPU，驅(qū)動(dòng)程序通過調(diào)度內(nèi)核線程來處理網(wǎng)絡(luò)包數(shù)據(jù)，處理完成后進(jìn)行下一包的接收；

2. 網(wǎng)卡全虛擬化

2.1 全虛擬化方案

全虛擬化方案，通過軟件來模擬網(wǎng)卡，Qemu+KVM的方案如下圖：

• Qemu中，設(shè)備的模擬稱為前端，比如e1000，前端與后端通信，后端再與底層通信，我們來分別看看發(fā)送和接收處理的流程；

• 發(fā)送：

  1. Guest OS在準(zhǔn)備好網(wǎng)絡(luò)包數(shù)據(jù)以及描述符資源后，通過寫TDT寄存器，觸發(fā)VM的異常退出，由KVM模塊接管；
  2. KVM模塊返回到Qemu后，Qemu會(huì)檢查VM退出的原因，比如檢查到e1000寄存器訪問出錯(cuò)，因而觸發(fā)e1000前端工作；
  3. Qemu能訪問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è)備；
  4. 數(shù)據(jù)發(fā)送完成后，除了更新ring-buffer的指針及描述符狀態(tài)信息外，KVM模塊會(huì)模擬TX中斷；
  5. 當(dāng)再次進(jìn)入VM時(shí)，Guest OS看到的是數(shù)據(jù)已經(jīng)發(fā)送完畢，同時(shí)還需要進(jìn)行中斷處理；
  6. Guest OS跑在vCPU線程中，發(fā)送數(shù)據(jù)時(shí)相當(dāng)于會(huì)打算它的執(zhí)行，直到處理完后再恢復(fù)回來，也就是一個(gè)嚴(yán)格的同步處理過程；

• 接收：

  1. 當(dāng)TUN/TAP有網(wǎng)絡(luò)包數(shù)據(jù)時(shí)，可以通過讀取TAP文件描述符來獲?。?/li>
  2. Qemu中的I/O線程會(huì)被喚醒并觸發(fā)后端處理，并將數(shù)據(jù)發(fā)送給e1000前端；
  3. e1000前端將數(shù)據(jù)拷貝到Guest OS的物理內(nèi)存中，并模擬RX中斷，觸發(fā)VM的退出，并由KVM模塊接管；
  4. KVM模塊返回到Qemu中進(jìn)行處理后，并最終重新進(jìn)入Guest OS的執(zhí)行中斷處理；
  5. 由于有I/O線程來處理接收，能與vCPU線程做到并行處理，這一點(diǎn)與發(fā)送不太一樣；

2.2 弊端

• Guest OS去操作寄存器的時(shí)候，會(huì)觸發(fā)VM退出，涉及到KVM和Qemu的處理，并最終再次進(jìn)入VM，overhead較大；
• 不管是在Host還是Guest中，中斷處理的開銷也很大，中斷涉及的寄存器訪問也較多；
• 軟件模擬的方案，吞吐量性能也比較低，時(shí)延較大；

所以，讓我們大聲喊出本文的主角吧！

3. 網(wǎng)卡半虛擬化

在進(jìn)入主題前，先思考幾個(gè)問題：

1. 全虛擬化下Guest可以重用驅(qū)動(dòng)、網(wǎng)絡(luò)協(xié)議棧等，但是在軟件全模擬的情況下，我們是否真的需要去訪問寄存器嗎（比如中斷處理），真的需要模擬網(wǎng)卡的自協(xié)商機(jī)制以及EEPROM等功能嗎？
2. 是否真的需要模擬大量的硬件控制寄存器，而這些寄存器在軟件看來毫無意義？
3. 是否真的需要生產(chǎn)者/消費(fèi)者模型的通知機(jī)制（寄存器訪問、中斷）？

3.1 virtio

網(wǎng)卡的工作過程是一個(gè)生產(chǎn)者消費(fèi)者模型，但是在前文中可以看出，在全虛擬化狀態(tài)下存在一些弊端，一個(gè)更好的生產(chǎn)者消費(fèi)者模型應(yīng)該遵循以下原則：

1. 寄存器只被生產(chǎn)者使用去通知消費(fèi)者ring-buffer有數(shù)據(jù)（消費(fèi)者可以繼續(xù)消費(fèi)），而不再被用作存儲(chǔ)狀態(tài)信息；
2. 中斷被消費(fèi)者用來通知生產(chǎn)者ring-buffer是非滿狀態(tài)（生產(chǎn)者可以繼續(xù)生產(chǎn)）；
3. 生產(chǎn)者和消費(fèi)者的狀態(tài)信息應(yīng)該存儲(chǔ)在內(nèi)存中，這樣讀取狀態(tài)信息時(shí)不需要VM退出，減少overhead；
4. 生產(chǎn)者和消費(fèi)者跑在不同的線程中，可以并行運(yùn)行，并且盡可能多的處理任務(wù)；
5. 非必要情況下，相互之間的通知應(yīng)該避免使用；
6. 忙等待（比如輪詢）不是一個(gè)可以接受的通用解決方案；

基于上述原則，我們來看看從特殊到一般的過程：

• 第一行是針對網(wǎng)卡的實(shí)現(xiàn)，第二行更進(jìn)一步的抽象，第三行是通用的解決方案了，對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ī)范來定義標(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格式的消息，而對端（virtio-net frontend）則是做相反的工作；

virtio的數(shù)據(jù)傳遞使用scatter-gather list（sg-list）：

• sg-list是概念上的（物理）地址和長度對的鏈表，通常作為數(shù)組來實(shí)現(xiàn)；
• 每個(gè)sg-list描述一個(gè)多塊的buffer，消費(fèi)者用它來作為輸入或輸出操作；

 
virtio的核心是virtqueue(VQ)的抽象：

• VQ是隊(duì)列，sg-list會(huì)被Guest的驅(qū)動(dòng)放置到VQ中，以供Hypervisor來消費(fèi)；
• 輸出sg-list用于向Hypervisor來發(fā)送數(shù)據(jù)，而輸入sg-list用于接收Hypervisor的數(shù)據(jù)；
• 驅(qū)動(dòng)可以使用一個(gè)或多個(gè)virqueue；

1. 當(dāng)Guest的驅(qū)動(dòng)產(chǎn)生一個(gè)sg-list時(shí)，調(diào)用add_buf(SG, Token)入列；
2. Hypervisor進(jìn)行出列操作，并消費(fèi)sg-list，并將sg-list push回去；
3. Guest通過get_buf()進(jìn)行清理工作；

上圖說的是數(shù)據(jù)流方向，那么事件的通知機(jī)制如下：

• 當(dāng)Guest驅(qū)動(dòng)想要Hypervisor消費(fèi)sg-list時(shí)，通過VQ的kick來進(jìn)行通知；
• 當(dāng)Hypervisor通知Guest驅(qū)動(dòng)已經(jīng)消費(fèi)完了，通過interupt來進(jìn)行通知；

大體的數(shù)據(jù)流和控制流講完了，細(xì)節(jié)實(shí)現(xiàn)后續(xù)再跟進(jìn)了。

3.2 半虛擬化方案

那么，半虛擬化框架下的網(wǎng)卡虛擬化數(shù)據(jù)流是啥樣的呢？

• 發(fā)送

• 接收

相信你應(yīng)該對virtio有個(gè)大概的了解了，好了，收工。

參考

《Virtio networking: A case study of I/O paravirtualization》
《 PCI/PCI-X Family of Gigabit Ethernet Controllers Software Developer's Manual》