背景
Read the fucking source code!--By 魯迅A picture is worth a thousand words.--By 高爾基
說明：
- KVM版本：5.9.1
- QEMU版本：5.0.0
- 工具：Source Insight 3.5， Visio
概述
- 從本文開始將研究一下virtio；
- 本文會從一個網卡虛擬化的例子來引入virtio，並從大體架構上進行介紹，有個宏觀的認識；
- 細節的闡述後續的文章再跟進；
1. 網卡
1.1 網卡工作原理
先來看一下網卡的架構圖（以Intel的82540爲例）：
- OSI模型，將網絡通信中的數據流劃分爲7層，最底下兩層爲物理層和數據鏈路層，對應到網卡上就是
PHY和MAC控制器； PHY：對應物理層，負責通信設備與網絡媒介（網線）之間的互通，它定義傳輸的光電信號、線路狀態等；MAC控制器：對應數據鏈路層，負責網絡尋址、錯誤偵測和改錯等；PHY和MAC通過MII/GMII(Media Independent Interface)和MDIO(Management Data Input/output)相連；MII/GMII(Gigabit MII)：由IEEE定義的以太網行業標準，與媒介無關，包含數據接口和管理接口，用於網絡數據傳輸；MDIO接口，也是由IEEE定義，一種簡單的串行接口，通常用於控制收發器，並收集狀態信息等；- 網卡通過PCI接口接入到PCI總線中，CPU可以通過訪問BAR空間來獲取數據包，也有網卡直接掛在內存總線上；
- 網卡還有一顆EEPROM芯片，用於記錄廠商ID、網卡的MAC地址、配置信息等；
我們主要關心它的數據流，所以，看看它的工作原理吧：
- 網絡包的接收與發送，都是典型的
生產者-消費者模型，簡單來說，CPU會在內存中維護兩個ring-buffer，分別代表RX和TX，ring-buffer中存放的是描述符，描述符裏包含了一個網絡包的信息，包括了網絡包地址、長度、狀態等信息； ring-buffer有頭尾兩個指針，發送端爲：TDH(Transmit Descriptor Head)和TDT(Transmit Descriptor Tail)，同理，接收端爲：RDH(Receive Descriptor Head)和RDT(Receive Descriptor Tail)，在數據傳輸時，由CPU和網卡來分開更新頭尾指針的值，這也就是生產者更新尾指針，消費者更新頭指針，永遠都是消費者追着生產者跑，ring-buffer也就能轉起來了；- 數據的傳輸，使用DMA來進行搬運，CPU的拷貝顯然是一種低效的選擇。在之前PCI系列分析文章中分析過，PCI設備有自己的BAR空間，可以通過DMA在BAR空間和DDR空間內進行搬運；
1.2 Linux網卡驅動
在網卡數據流圖中，我們也基本看到了網卡驅動的影子，驅動與網卡之間是異步通信：
- 驅動程序負責硬件的初始化，以及TX和RX的
ring-buffer的創建及初始化； ndo_start_xmit負責將網絡包通過驅動程序發送出去，netif_receive_skb負責通過驅動程序接收網絡包數據；- 數據通過
struct sk_buff來存儲； - 發送數據時，CPU負責準備TX網絡包數據以及描述符資源，更新TDT指針，並通知NIC可以進行數據發送了，當數據發送完畢後NIC通過中斷信號通知CPU進行下一個包的處理；
- 接收數據時，CPU負責準備RX的描述符資源，接收數據後，NIC通過中斷通知CPU，驅動程序通過調度內核線程來處理網絡包數據，處理完成後進行下一包的接收；
2. 網卡全虛擬化
2.1 全虛擬化方案
全虛擬化方案，通過軟件來模擬網卡，Qemu+KVM的方案如下圖：
- Qemu中，設備的模擬稱爲前端，比如
e1000，前端與後端通信，後端再與底層通信，我們來分別看看發送和接收處理的流程；
-
發送：
- Guest OS在準備好網絡包數據以及描述符資源後，通過寫
TDT寄存器，觸發VM的異常退出，由KVM模塊接管； - KVM模塊返回到Qemu後，Qemu會檢查VM退出的原因，比如檢查到
e1000寄存器訪問出錯，因而觸發e1000前端工作； - Qemu能訪問Guest OS中的地址內容，因而
e1000前端能獲取到Guest OS內存中的網絡包數據，發送給後端，後端再將網絡包數據發送給TUN/TAP驅動，其中TUN/TAP爲虛擬網絡設備； - 數據發送完成後，除了更新
ring-buffer的指針及描述符狀態信息外，KVM模塊會模擬TX中斷； - 當再次進入VM時，Guest OS看到的是數據已經發送完畢，同時還需要進行中斷處理；
- Guest OS跑在vCPU線程中，發送數據時相當於會打算它的執行，直到處理完後再恢復回來，也就是一個嚴格的同步處理過程；
- Guest OS在準備好網絡包數據以及描述符資源後，通過寫
-
接收：
- 當TUN/TAP有網絡包數據時，可以通過讀取TAP文件描述符來獲取；
- Qemu中的I/O線程會被喚醒並觸發後端處理，並將數據發送給
e1000前端； e1000前端將數據拷貝到Guest OS的物理內存中，並模擬RX中斷，觸發VM的退出，並由KVM模塊接管；- KVM模塊返回到Qemu中進行處理後，並最終重新進入Guest OS的執行中斷處理；
- 由於有I/O線程來處理接收，能與vCPU線程做到並行處理，這一點與發送不太一樣；
2.2 弊端
- Guest OS去操作寄存器的時候，會觸發VM退出，涉及到KVM和Qemu的處理，並最終再次進入VM，overhead較大；
- 不管是在Host還是Guest中，中斷處理的開銷也很大，中斷涉及的寄存器訪問也較多；
- 軟件模擬的方案，吞吐量性能也比較低，時延較大；
所以，讓我們大聲喊出本文的主角吧！
3. 網卡半虛擬化
在進入主題前，先思考幾個問題：
- 全虛擬化下Guest可以重用驅動、網絡協議棧等，但是在軟件全模擬的情況下，我們是否真的需要去訪問寄存器嗎（比如中斷處理），真的需要模擬網卡的自協商機制以及EEPROM等功能嗎？
- 是否真的需要模擬大量的硬件控制寄存器，而這些寄存器在軟件看來毫無意義？
- 是否真的需要生產者/消費者模型的通知機制（寄存器訪問、中斷）？
3.1 virtio
網卡的工作過程是一個生產者消費者模型，但是在前文中可以看出，在全虛擬化狀態下存在一些弊端，一個更好的生產者消費者模型應該遵循以下原則：
- 寄存器只被生產者使用去通知消費者
ring-buffer有數據（消費者可以繼續消費），而不再被用作存儲狀態信息； - 中斷被消費者用來通知生產者
ring-buffer是非滿狀態（生產者可以繼續生產）； - 生產者和消費者的狀態信息應該存儲在內存中，這樣讀取狀態信息時不需要VM退出，減少overhead；
- 生產者和消費者跑在不同的線程中，可以並行運行，並且儘可能多的處理任務；
- 非必要情況下，相互之間的通知應該避免使用；
- 忙等待（比如輪詢）不是一個可以接受的通用解決方案；
基於上述原則，我們來看看從特殊到一般的過程：
- 第一行是針對網卡的實現，第二行更進一步的抽象，第三行是通用的解決方案了，對I/O操作的虛擬化通用支持；
所以，在virtio的方案下，網卡的虛擬化看上去就是下邊這個樣子了：
- Hypervisor和Guest都需要實現virtio，這也就意味着Guest的設備驅動知道自己本身運行在VM中；
- virtio的目標是高性能的設備虛擬化，已經形成了規範來定義標準的消息傳遞API，用於驅動和Hypervisor之間的傳遞，不同的驅動和前端可以使用相同的API；
- virtio驅動（比如圖中的virtio-net driver）的工作是將OS-specific的消息轉換成virtio格式的消息，而對端（virtio-net frontend）則是做相反的工作；
virtio的數據傳遞使用scatter-gather list（sg-list）：
- sg-list是概念上的（物理）地址和長度對的鏈表，通常作爲數組來實現；
- 每個sg-list描述一個多塊的buffer，消費者用它來作爲輸入或輸出操作；
virtio的核心是virtqueue(VQ)的抽象：
- VQ是隊列，sg-list會被Guest的驅動放置到VQ中，以供Hypervisor來消費；
- 輸出sg-list用於向Hypervisor來發送數據，而輸入sg-list用於接收Hypervisor的數據；
- 驅動可以使用一個或多個
virqueue；
- 當Guest的驅動產生一個sg-list時，調用
add_buf(SG, Token)入列； - Hypervisor進行出列操作，並消費sg-list，並將sg-list push回去；
- Guest通過
get_buf()進行清理工作；
上圖說的是數據流方向，那麼事件的通知機制如下：
- 當Guest驅動想要Hypervisor消費sg-list時，通過VQ的
kick來進行通知； - 當Hypervisor通知Guest驅動已經消費完了，通過
interupt來進行通知；
大體的數據流和控制流講完了，細節實現後續再跟進了。
3.2 半虛擬化方案
那麼，半虛擬化框架下的網卡虛擬化數據流是啥樣的呢？
- 發送
- 接收
相信你應該對virtio有個大概的瞭解了，好了，收工。
參考
《Virtio networking: A case study of I/O paravirtualization》
《 PCI/PCI-X Family of Gigabit Ethernet Controllers Software Developer's Manual》
歡迎關注個人公衆號，不定期更新Linux相關技術文章。
