背景

說明：

概述

先來看一下網卡的架構圖（以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空間內進行搬運；

在網卡資料流圖中，我們也基本看到了網卡驅動的影子，驅動與網卡之間是異步通信：

驅動程式負責硬體的初始化，以及TX和RX的ring-buffer的創建及初始化；
ndo_start_xmit負責將網路包通過驅動程式發送出去，netif_receive_skb負責通過驅動程式接收網路包資料；
資料通過struct sk_buff來存盤；
發送資料時，CPU負責準備TX網路包資料以及描述符資源，更新TDT指標，并通知NIC可以進行資料發送了，當資料發送完畢后NIC通過中斷信號通知CPU進行下一個包的處理；
接收資料時，CPU負責準備RX的描述符資源，接收資料后，NIC通過中斷通知CPU，驅動程式通過調度內核執行緒來處理網路包資料，處理完成后進行下一包的接收；

全虛擬化方案，通過軟體來模擬網卡，Qemu+KVM的方案如下圖：

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

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

全虛擬化下Guest可以重用驅動、網路協議堆疊等，但是在軟體全模擬的情況下，我們是否真的需要去訪問暫存器嗎（比如中斷處理），真的需要模擬網卡的自協商機制以及EEPROM等功能嗎？
是否真的需要模擬大量的硬體控制暫存器，而這些暫存器在軟體看來毫無意義？
是否真的需要生產者/消費者模型的通知機制（暫存器訪問、中斷）？

網卡的作業程序是一個生產者消費者模型，但是在前文中可以看出，在全虛擬化狀態下存在一些弊端，一個更好的生產者消費者模型應該遵循以下原則：

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

所以，在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）：