背景

• 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；
• 本文會從一個網(wǎng)卡虛擬化的例子來引入virtio，并從大體架構(gòu)上進行介紹，有個宏觀的認識；
• 細節(jié)的闡述后續(xù)的文章再跟進；

1. 網(wǎng)卡

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

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

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

1.2 Linux網(wǎng)卡驅(qū)動

在網(wǎng)卡數(shù)據(jù)流圖中，我們也基本看到了網(wǎng)卡驅(qū)動的影子，驅(qū)動與網(wǎng)卡之間是異步通信：

• 驅(qū)動程序負責硬件的初始化，以及TX和RX的ring-buffer的創(chuàng)建及初始化；
• ndo_start_xmit負責將網(wǎng)絡包通過驅(qū)動程序發(fā)送出去，netif_receive_skb負責通過驅(qū)動程序接收網(wǎng)絡包數(shù)據(jù)；
• 數(shù)據(jù)通過struct sk_buff來存儲；
• 發(fā)送數(shù)據(jù)時，CPU負責準備TX網(wǎng)絡包數(shù)據(jù)以及描述符資源，更新TDT指針，并通知NIC可以進行數(shù)據(jù)發(fā)送了，當數(shù)據(jù)發(fā)送完畢后NIC通過中斷信號通知CPU進行下一個包的處理；
• 接收數(shù)據(jù)時，CPU負責準備RX的描述符資源，接收數(shù)據(jù)后，NIC通過中斷通知CPU，驅(qū)動程序通過調(diào)度內(nèi)核線程來處理網(wǎng)絡包數(shù)據(jù)，處理完成后進行下一包的接收；

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

2.1 全虛擬化方案

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

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

• 發(fā)送：

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

• 接收：

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

2.2 弊端

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

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

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

在進入主題前，先思考幾個問題：

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

3.1 virtio

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

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

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

• 第一行是針對網(wǎng)卡的實現(xiàn)，第二行更進一步的抽象，第三行是通用的解決方案了，對I/O操作的虛擬化通用支持；

所以，在virtio的方案下，網(wǎng)卡的虛擬化看上去就是下邊這個樣子了：

• Hypervisor和Guest都需要實現(xiàn)virtio，這也就意味著Guest的設備驅(qū)動知道自己本身運行在VM中；
• virtio的目標是高性能的設備虛擬化，已經(jīng)形成了規(guī)范來定義標準的消息傳遞API，用于驅(qū)動和Hypervisor之間的傳遞，不同的驅(qū)動和前端可以使用相同的API；
• virtio驅(qū)動（比如圖中的virtio-net driver）的工作是將OS-specific的消息轉(zhuǎn)換成virtio格式的消息，而對端（virtio-net frontend）則是做相反的工作；

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

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

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

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

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

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

• 當Guest驅(qū)動想要Hypervisor消費sg-list時，通過VQ的kick來進行通知；
• 當Hypervisor通知Guest驅(qū)動已經(jīng)消費完了，通過interupt來進行通知；

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

3.2 半虛擬化方案

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

• 發(fā)送

• 接收

相信你應該對virtio有個大概的了解了，好了，收工。

參考

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