2.2 Virtqueue交互隊列

Virtio 1.1引入了Packed Virtqueue的概念，對應的Virtio 1.0的Virtqueue被稱為Split Virtqueue。

如圖3所示，為Virtio1.0的Split Virtqueue結構。Virtqueue由三部分組成：

• 描述符表
• 可用的描述符環
• 已使用的描述符環
• Virtio 1.0的Split Virtqueue具有一些缺點：
• 如果是虛擬化場景軟件模擬Virtio設備的話，因為分散的數據結構，導致Cache利用率較低，每次請求都會有很多Cache不命中；
• 如果是硬件實現的話，每次描述符需要多次設備DMA訪問。

圖3 Virtio 1.0中的Split Virtqueue

如圖4所示，Virtio 1.1引入了Packed Virtqueue的概念。整個描述符只有一個數據結構。這樣，如果軟件實現Virtio設備模擬的話，可以提升描述符交互的Cache命中率。如果硬件實現的，可以降低設備DMA的訪問次數。

圖4 Virtio1.1的Packed Virtqueue

2.3 Virtio交互

驅動和設備的交互，符合生產者消費者模型的數據及通知（Notification）的交互行為。驅動把共享隊列的隊列項準備好，通過寫寄存器的方式通知設備。設備收到驅動發送的通知則處理隊列項以及相應的數據搬運工作，結束后更新隊列狀態并通知（設備通知驅動是通過中斷）驅動。驅動接收到中斷通知時候，把已經使用的隊列項釋放，并更新隊列狀態。

一個典型的通用的驅動和設備的交互流程如圖5所示。Virtio場景的驅動和設備交互，驅動給設備的通知（Notification）稱為Kick，設備給驅動的通知稱為Interrupt（中斷）。Kick和Interrupt操作是Virtio接口的一部分，在虛擬化場景，Kick和Interrupt需要非常大的CPU切換代價。驅動希望在Kick之前產生盡可能多的待處理緩沖項（一個緩沖項對應一個描述符和描述符指向的數據塊）；同樣的，設備希望處理盡可能多的緩沖項然后再發送一個中斷。通過盡量處理更多的緩沖項的方式，來攤薄通知的代價。

這種策略是一種理想狀態，因為大多數時候驅動并不知道下一組緩沖項何時帶來，因此不得不每一組緩沖項準備好之后就必須要Kick設備。同樣的，設備在處理完相應的緩沖項之后，就盡快的發送中斷給驅動，以達到盡可能小的延遲。

圖5 Virtio驅動和設備交互示意圖

如圖6所示，在設備模擬的虛擬化場景下，驅動可以暫時禁用中斷，設備也可以暫時禁用Kick。通過這樣的機制，可以最大限度的減少通知的代價，并且不影響性能和延遲。Virtio 1.1支持兩種通知抑制機制，因此共有三種模式：

• 使能通知模式：完全無抑制，使能通知；
• 禁用通知模式：如圖6所示，可以完全禁止對方發通知給自己；
• 使能特定的描述符通知模式：告知對方一個特定的描述符，當對方順序處理到此描述符處理完成時產生通知。

圖6 通過前后端禁用抑制通知的Virtio驅動和設備交互

2.4 總結

如圖7，Virtio基于分層的設計思想，定義了三層Virtio設備架構：

• 最下層的總線接口。PCI是最常用的Virtio場景使用的總線，但Virtio協議不僅僅支持PCI，也支持MMIO和Channel IO等。
• 通用的Virtio交互接口。包括Virtqueue、功能特征位、配置空間等。Virtio交互接口是Virtio最核心的功能，通過Virtio交互接口實現了不同類型設備的標準化。
• 上層的特定設備接口。在Virtio協議里，定義網絡、塊、控制臺、SCSI、GPU等各種不同類型的設備。

圖7 分層的Virtio框架圖

Virtio的優點體現在：

• Virtio實現了盡可能多的設計共享。這樣，在開發的時候就可以復用很多軟件和硬件資源，達到快速開發的目的。
• Virtio實現了接口的標準化。標準化體現在兩個方面：
• (1)一個是通用的Virtio交互接口，統一了不同的設備類型軟硬件交互；
• (2)另一個是基于Virtio的Virtio-net、Virtio-block等廣泛應用于云計算虛擬化場景，Virtio已經成為事實上的標準I/O接口。

而Virtio的缺點，則同樣因為Virtio實現了接口的標準化，而忽略了不同設備類型數據傳輸的特點。因此，在一些大數據量傳輸的場景，效率比較低下。如果是在類似HPC這樣的性能和延遲非常敏感的場景，Virtio就不是一個很好的選擇。

**03 **虛擬化卸載

虛擬化卸載指的是計算機虛擬化中消耗CPU資源較多的接口設備模擬、熱遷移、虛擬化管理等任務的卸載。

a. 接口設備的卸載

前面我們介紹了網絡、遠程存儲等IO工作任務的卸載，而虛擬化卸載主要指的是跟IO相關的接口設備的卸載，例如網絡、存儲等接口設備的卸載。IO接口設備的卸載本身上也是IO硬件虛擬化的過程，比如我們通過VT-d技術實現從VM中pass though訪問硬件設備，某種程度上也可以認為是把運行在Hypervisor中的模擬設備 “卸載”到了硬件。因此，IO接口設備的卸載本質上和IO設備硬件虛擬化是一件事情。

如圖8，為了實現設備接口的標準化、加速IO處理的性能以及潛在的充分利用現有的虛擬化生態（例如更好的支持設備熱遷移）等原因，阿里云在神龍芯片里實現了硬件的Virtio接口設備，通過Virtio接口設備支持Virtio-net網絡驅動和Virtio-blk存儲驅動等，實現了類虛擬化IO設備Virtio的硬件“卸載”。

圖8 阿里云神龍芯片網絡和存儲接口示意圖

AWS的NITRO系統支持網絡、本地存儲和遠程存儲，NITRO實現了網絡接口設備ENA/EFA（AWS自定義接口）的硬件“卸載”以及存儲接口設備NVMe（遠程存儲EBS使用的是NVMe接口，本地存儲也是NVMe接口）的卸載。

b. 接口設備卸載后的遷移問題

當把設備“卸載”到硬件，讓VM直接訪問硬件設備，這使得VM的設備熱遷移變的非常有挑戰。vDPA（vhost Data Path Acceleration，vhost數據路徑加速，其中vhost是Virtio后端設備模擬的輪詢方式實現）實現了一種折中的解決方案，如圖9所示，vDPA把Virtio分為了控制面和數據面：

• 控制面。vDPA控制面依然是通過要經過Hypervisor的處理，用于設備和VM之間的配置更改和功能協商，用于建立和終止數據面。
• 數據面。vDPA數據面包括共享隊列以及相應的通知機制，用于在設備和VM之間傳輸實際的數據。

圖9 vDPA框架示意圖

使用vDPA一個重要原因是，在熱遷移的時候可以很方便的把Virtio數據面的處理切換回傳統的Virtio/Vhost后端設備模擬。這樣，可以充分利用現有的基于KVM/Qemu對Virtio設備遷移的解決方案來完成設備的遷移。

c. 虛擬化管理的卸載

從軟件虛擬化進化到硬件虛擬化的過程，本身就可以看作是一個硬件加速以及硬件卸載的過程。我們逐步的剝離了Hypervisor的功能，比如通過VT-x技術“卸載”了Hypervisor的CPU/內存等的軟件模擬，以及通過VT-d以及vDPA等技術“卸載”了設備軟件模擬。這些剝離，使得Hypervisor越來越輕量，整個系統的虛擬化開銷也越來越少。進一步的，我們可以把虛擬化的管理（例如Linux平臺主流的管理程序Libvirt）卸載到硬件中的嵌入式軟件運行。

如圖10， 我們通過橋接的方式，實現主機軟件和硬件中嵌入式軟件通信機制。把虛擬化管理等軟件任務從主機卸載到嵌入式系統（依然有很小一部分任務無法卸載，如虛擬機資源分配、vCPU調度等）。這樣，可以把幾乎100%的主機資源提供給用戶，使用戶虛擬機得到近乎物理機的性能。

圖10 虛擬化管理卸載圖

通過虛擬化管理卸載到硬件中的嵌入式CPU軟件，我們可以做到物理上的業務和管理分離，整個業務主機跟云計算管理網絡安全的隔離，只能通過特定的接口訪問到Lite Hypervisor，除此之外，不能訪問主機的任何資源。這樣，即使有潛在的運維操作失誤，也無法對業務主機造成影響。