【原創】Linux虛擬化KVM-Qemu分析（八）之virtio初探

LoyenWang發表於2021-01-24

背景

說明：

先來看一下網路卡的架構圖（以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）：