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

背景

• 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；
• 本文會從一個網卡虛擬化的例子來引入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，前端與後端通訊，後端再與底層通訊，咱們來分別看看發送和接收處理的流程；

 

• 發送：

  1. Guest OS在準備好網絡包數據以及描述符資源後，經過寫TDT寄存器，觸發VM的異常退出，由KVM模塊接管；
  2. KVM模塊返回到Qemu後，Qemu會檢查VM退出的緣由，好比檢查到e1000寄存器訪問出錯，於是觸發e1000前端工做；
  3. Qemu能訪問Guest OS中的地址內容，於是e1000前端能獲取到Guest OS內存中的網絡包數據，發送給後端，後端再將網絡包數據發送給TUN/TAP驅動，其中TUN/TAP爲虛擬網絡設備；
  4. 數據發送完成後，除了更新ring-buffer的指針及描述符狀態信息外，KVM模塊會模擬TX中斷；
  5. 當再次進入VM時，Guest OS看到的是數據已經發送完畢，同時還須要進行中斷處理；
  6. Guest OS跑在vCPU線程中，發送數據時至關於會打算它的執行，直處處理完後再恢復回來，也就是一個嚴格的同步處理過程；

• 接收：

  1. 當TUN/TAP有網絡包數據時，能夠經過讀取TAP文件描述符來獲取；
  2. Qemu中的I/O線程會被喚醒並觸發後端處理，並將數據發送給e1000前端；
  3. e1000前端將數據拷貝到Guest OS的物理內存中，並模擬RX中斷，觸發VM的退出，並由KVM模塊接管；
  4. KVM模塊返回到Qemu中進行處理後，並最終從新進入Guest OS的執行中斷處理；
  5. 因爲有I/O線程來處理接收，能與vCPU線程作到並行處理，這一點與發送不太同樣；

2.2 弊端

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

因此，讓咱們大聲喊出本文的主角吧！

3. 網卡半虛擬化

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

1. 全虛擬化下Guest能夠重用驅動、網絡協議棧等，可是在軟件全模擬的狀況下，咱們是否真的須要去訪問寄存器嗎（好比中斷處理），真的須要模擬網卡的自協商機制以及EEPROM等功能嗎？
2. 是否真的須要模擬大量的硬件控制寄存器，而這些寄存器在軟件看來毫無心義？
3. 是否真的須要生產者/消費者模型的通知機制（寄存器訪問、中斷）？

3.1 virtio

網卡的工做過程是一個生產者消費者模型，可是在前文中能夠看出，在全虛擬化狀態下存在一些弊端，一個更好的生產者消費者模型應該遵循如下原則：

1. 寄存器只被生產者使用去通知消費者ring-buffer有數據（消費者能夠繼續消費），而再也不被用做存儲狀態信息；
2. 中斷被消費者用來通知生產者ring-buffer是非滿狀態（生產者能夠繼續生產）；
3. 生產者和消費者的狀態信息應該存儲在內存中，這樣讀取狀態信息時不須要VM退出，減小overhead；
4. 生產者和消費者跑在不一樣的線程中，能夠並行運行，而且儘量多的處理任務；
5. 非必要狀況下，相互之間的通知應該避免使用；
6. 忙等待（好比輪詢）不是一個能夠接受的通用解決方案；

基於上述原則，咱們來看看從特殊到通常的過程：

• 第一行是針對網卡的實現，第二行更進一步的抽象，第三行是通用的解決方案了，對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；

1. 當Guest的驅動產生一個sg-list時，調用add_buf(SG, Token)入列；
2. Hypervisor進行出列操做，並消費sg-list，並將sg-list push回去；
3. 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相關技術文章。