目錄：
- 虛擬化
- dpdk的實現研究
- virtio
- vhost
- SR-IOV
- 熱遷移相關
- 研究拓展
本文記錄近期對dpdk在虛擬化和雲計算領域應用的研究成果，內容梳理如下。
虛擬化
虛擬化，抽象來說，就是將物理資源邏輯化。具體來說，虛擬技術的實現是在系統中加入一個虛擬化層（也就是hypervisor）,將下層的物理資源（如disk,nic,cpu,memory等）抽象成另一種形式的資源，提供給上層應用，通過空間上的分割，時間上的分時以及模擬，將一份資源抽象成多份。
虛擬化能帶來的好處不言而喻，可以顯著提高物理資源的使用效率，能夠進行動態分配、資源管理和負載的相互隔離，並提供高安全性和自動化。虛擬化還為雲計算提供支持，主要提供按需的服務配置和軟件定義的資源編排等。
X86平台的虛擬化實現主要有三部分：CPU虛擬化、內存虛擬化和IO虛擬化。
- CPU虛擬化
intel引入VT-x來提升CPU虛擬化效率和虛擬機安全性(參見圖1)。VT-x擴展了傳統的x86處理器架構，它引入了兩種操作模式：VMX root operation（根虛擬化操作）和VMX non-root operation（非根虛擬化操作），統稱為VMX操作模式。 此外，還支持虛機熱遷移特性。
圖1.支持intel VT-x的虛擬化架構
為了建立這種兩個操作模式的架構，VT-x設計了一個Virtual-Machine Control Structure（VMCS，虛擬機控制結構）的數據結構，包括了Guest-State Area（客戶狀態區）和Host-State Area（主機狀態區），用來保存虛擬機以及主機的各種狀態參數，並提供了VM entry和VM exit兩種操作在虛擬機與VMM之間切換，並在切換時會自動查詢和更新VMCS，加速guest狀態切換時間。這樣非根模式下敏感指令不再是直接執行或者通過陷入再模擬的方式執行，而是通過VM exit和VM entry這兩個操作完成切換，既解決了虛擬機的隔離問題，又解決了性能問題。
關於VT-x的詳細介紹，還可以參考這里和這里。 - 內存虛擬化
內存虛擬化的核心任務是實現地址空間虛擬化，一般的實現原理是這樣的：
圖2：地址空間虛擬化實現
通過兩次地址轉化來支持地址空間虛擬化：GVA(Guest Virtual Address)->GPA(Guest Physical Address)->GMA(Host Physical Address).其中VA->PA的轉換由guest完成，通常是通過VMCS中的客戶機狀態域CR3指向的頁表來指定；PA->MA的轉換由宿主機完成，一般在guest建立時就分配好固定的物理內存，並采用一定的數據結構記錄響應的映射關系。
傳統的IA架構只支持一次地址轉換，即CR3指向的頁表來實現虛擬地址到物理地址的轉化（即VA->PA的轉化），這和上面的過程中要求的兩次地址轉換是矛盾的，因此為解決這個問題，Intel引入了VT-x技術，在原有的一次地址轉換基礎上，又引入了EPT頁表實現PA->MA的轉換，從而在硬件上支持了兩次地址轉化，大大提高了地址轉換的性能。
關於EPT的工作原理如圖3描述:：
圖3：EPT工作原理
首先根據VA的地址和CR3指向的頁表計算出PA，在通過EPT頁表實現PA->MA的地址轉化。關於內存虛擬化的詳細介紹，還可以參考這里和這里。 - IO虛擬化
IO虛擬化包括管理虛擬設備和物理硬件之間的IO請求的路由選擇。實現方式可以划分為：全虛擬化、半虛擬化，IO透傳，SR-IOV。
其中全虛擬化是指客戶機的所有功能或總線結構都可以在宿主機上進行模擬，宿主機通過截獲客戶機的I/O請求，通過軟件來完全模擬硬件。盡管這樣模擬得很徹底，但效率卻比較低（需要由VMM來捕獲特權指令和翻譯地址）。
半虛擬化是指客戶機能夠感知自己是虛擬機，執行特權指令時直接向hypervisor call調用，省去指令的翻譯過程，從而提升性能。
I/O透傳是指直接將物理設備分配給虛擬使用，這種方式需要硬件平台具備I/O透傳技術，能獲取到近乎本地的性能，且CPU開銷小。透傳的使用通常結合intel VT-D來使用。
SR-IOV主要用來解決透傳時一個物理硬件只能被一台虛擬子機訪問的問題。SR-IOV需要網卡硬件支持，支持SR-IOV功能的網卡（PF）可以在Hypervior里面注冊成多個網卡(VF)(每個網卡都獨立的中斷ID、收發隊列、QOS管理機制),每個VF可以通過pass-through方式分配給虛擬子機。
關於這塊的資料比較多，就不展開介紹，想了解的可以點這里和這里。
DPDK通過virtio和vhost PMD來實現IO的半虛擬化功能。此外，DPDK還支持I/O透傳，SR-IOV等特性，進一步提升IO性能。
除了X86服務器平台的虛擬化，還有些比較重要的領域就是網絡虛擬化(NFV)和軟件定義網絡(SDN)。
- NFV
即網絡功能虛擬化，Network Function Virtualization。通過使用x86等通用性硬件以及虛擬化技術，來承載很多功能的軟件處理。從而降低網絡昂貴的設備成本。可以通過軟硬件解耦及功能抽象，使網絡設備功能不再依賴於專用硬件，資源可以充分靈活共享，實現新業務的快速開發和部署，並基於實際業務需求進行自動部署、彈性伸縮、故障隔離和自愈等。關於NFV的概念可以參考這里。
其中NFV框架中所有的軟件功能都由虛擬的VNF來實現，虛機本身的性能就存在很大的優化空間。當考慮VNF性能時，需要考慮本身的架構設計，以及NFVI能夠提供的硬件資源能力和交互接口等等。
一般上在系統整體架構上需要考慮如下幾點：- VNF本身特性：計算密集型？IO密集型？內存密集型？有可能是多種特性集一身
- 系統資源的分配：評估VNF或者VNF子模塊對處理器、內存、存儲、網絡的需求
- 網卡虛擬化接口的選擇：是否獨占物理網卡，獨占的化使用透傳技術，否則需要共享。還需要考慮接口的性能、遷移性、維護性、安全性等
- 網卡輪詢和中斷模式的選擇：輪詢模式CPU占比高，但網絡吞吐性能高，100%占有一個core來進行收包是否合理？ 中斷模式CPU占有率低，但處理小包的性能不高
- 硬件加速功能的考慮：支持硬件卸載的網卡，定制的FPGA，QAT加速卡等是否可以和業務配合使用？
- QOS保證：多VNF運行在同一台服務器時，由於物理資源共享，各VNF對資源的使用率又不盡相同，可能會造成互相干擾性能下降
- 是否需要支持動態遷移：這個對IO，內存，CPU等都會提出特殊要求
- SDN
SDN主要是一種實現網絡框架，最重要的三個概念是：可編程（開放的API接口）、控制平面與數據平面分離，以及集中式控制模型。基於SDN的網絡架構可以更容易地實現網絡虛擬化。關於SDN的概念討論可以參考這里。
目前DPDK對SDN的支持可以落在以下幾個點上：- 對數據轉發面的優化，包括提升VNF的性能、和ovs的結合
- SFC（軟件服務鏈）轉發性能優化，多個SF之間的數據交互，可以不用過vswitch，而是直接通過virtio-pci進行傳輸。
DPDK的實現
DPDK對I/O虛擬化的支持主要集中在I/O半虛擬化,通過提供virtio PMD 和 vhost后端加速驅動來提升I/O處理性能；此外，對於SR-IOV虛擬出來的PF和VF也提供了VMDQ來支持，下面來分別展開介紹。
virtio
virtio是一種半虛擬化的設備抽象接口規范，在guest操作系統中實現的前端驅動程序一般直接稱為virtio，在host操作系統實現的后端驅動從程序通常稱為vhost。與guest端純軟件模擬I/O（如e1000,rt18139）相比，virtio可以提供很好的I/O性能，雖然同I/O透傳技術或者SR-IOV技術相比，目前在網絡吞吐率、時延以及抖動性各方面相比都不具備優勢，相關的優化工作正在進行當中。此外，使用virtio技術可以支持虛擬機的動態遷移以及靈活的流分類規則。
圖4：常見的使用架構
virtio主要有兩個版本，0.95和1.0，其規定的實現接口有PCI，MMIO和Channel IO方式，其中Channel IO方式是在1.0版本中新增的。PCI是現代計算機系統中普遍使用的一種總線接口，最新規范為PCI-e，DPDK目前只支持PCI接口方式。
Virtio 使用 virtqueue 來實現其 I/O 機制，每個 virtqueue 就是一個承載大量數據的 queue。vring 是 virtqueue 的具體實現方式，針對 vring 會有相應的描述符表格進行描述。框架如下圖所示：
圖5 virtio詳細框架
其中比較重要的 幾個概念是：
- 設備的配置：初始化、配置PCI設備空間和特性、中斷配置和專屬配置
- 虛擬隊列的配置：virtqueue、vring、descriptor table、avaliable ring和used ring的使用
- 設備的使用
- 驅動向設備提供緩沖區並寫入數據
- 設備使用數據及歸還緩沖區
關於virtio的基本概念和設備操作可以參考這里，對於補充virtio相關基礎知識個人認為介紹的足夠了。
dpdk對virtio的實現
virtio在linux內核和dpdk都有相應的驅動，其中linux內核版本功能更加全面，dpdk版本更注重性能。可以先參考下內核中對virtio的實現抽象層次：
- 第一層抽象：底層PCI-e設備層，負責檢測PCI-e設備，並初始化設備對應的驅動程序,提供兩個抽象類:virtio_driver和virtio_device
- 第二層抽像：中間virio虛擬隊列層，實現virtqueue，提供類：vring_virtqueue,vring等
- 第三層抽象：上層網絡設備層，實現底層的兩個抽象類:virtio_net_driver和dev,能夠供應用軟件將其看成普通的網口使用
對應的dpdk驅動也是按照這個思路來進行實現的，pmd驅動文件的組成見下圖（參考17.05版本，目錄為：dpdk-17.05\drivers\net\virtio\）：
圖6:virtio pmd文件組成
除了上圖中框出的文件，還有和virtio_user相關的文件主要用來實現類似KNI的exception path，這塊內容放到其它篇幅再繼續研究，這里先跳過。
第一層抽象
//drivers\net\virio\virtio_pic.h
/*第一大塊：virtio設備的配置相關宏定義*/
/* VirtIO PCI vendor/device ID. */
#define VIRTIO_PCI_VENDORID 0x1AF4
#define VIRTIO_PCI_LEGACY_DEVICEID_NET 0x1000
#define VIRTIO_PCI_MODERN_DEVICEID_NET 0x1041
/*
* VirtIO Header, located in BAR 0
* 具體的相關宏定義可參考virtio設備標准
*/
#define VIRTIO_PCI_HOST_FEATURES 0 /* host's supported features (32bit, RO)*/
#define VIRTIO_PCI_GUEST_FEATURES 4 /* guest's supported features (32, RW) */
#define VIRTIO_PCI_QUEUE_PFN 8 /* physical address of VQ (32, RW) */
#define VIRTIO_PCI_QUEUE_NUM 12 /* number of ring entries (16, RO) */
#define VIRTIO_PCI_QUEUE_SEL 14 /* current VQ selection (16, RW) */
#define VIRTIO_PCI_QUEUE_NOTIFY 16 /* notify host regarding VQ (16, RW) */
#define VIRTIO_PCI_STATUS 18 /* device status register (8, RW) */
#define VIRTIO_PCI_ISR 19 /* interrupt status register, reading
* also clears the register (8, RO) */
/* Only if MSIX is enabled: */
#define VIRTIO_MSI_CONFIG_VECTOR 20 /* configuration change vector (16, RW) */
#define VIRTIO_MSI_QUEUE_VECTOR 22 /* vector for selected VQ notifications
(16, RW) */
/* The bit of the ISR which indicates a device has an interrupt. */
#define VIRTIO_PCI_ISR_INTR 0x1
/* The bit of the ISR which indicates a device configuration change. */
#define VIRTIO_PCI_ISR_CONFIG 0x2
/* Vector value used to disable MSI for queue. */
#define VIRTIO_MSI_NO_VECTOR 0xFFFF
/* VirtIO device IDs. virtio不止有網卡，還有存儲、內存等等*/
#define VIRTIO_ID_NETWORK 0x01
#define VIRTIO_ID_BLOCK 0x02
#define VIRTIO_ID_CONSOLE 0x03
#define VIRTIO_ID_ENTROPY 0x04
#define VIRTIO_ID_BALLOON 0x05
#define VIRTIO_ID_IOMEMORY 0x06
#define VIRTIO_ID_9P 0x09
/* Status byte for guest to report progress.
* 當驅動初始化一個virtio設備時，通過設備狀態來反應進度
*/
#define VIRTIO_CONFIG_STATUS_RESET 0x00
#define VIRTIO_CONFIG_STATUS_ACK 0x01
#define VIRTIO_CONFIG_STATUS_DRIVER 0x02
#define VIRTIO_CONFIG_STATUS_DRIVER_OK 0x04
#define VIRTIO_CONFIG_STATUS_FEATURES_OK 0x08
#define VIRTIO_CONFIG_STATUS_FAILED 0x80
/*
* Each virtqueue indirect descriptor list must be physically contiguous.
* To allow us to malloc(9) each list individually, limit the number
* supported to what will fit in one page. With 4KB pages, this is a limit
* of 256 descriptors. If there is ever a need for more, we can switch to
* contigmalloc(9) for the larger allocations, similar to what
* bus_dmamem_alloc(9) does.
*
* Note the sizeof(struct vring_desc) is 16 bytes.
*/
#define VIRTIO_MAX_INDIRECT ((int) (PAGE_SIZE / 16))
/* The feature bitmap for virtio net
* 對網卡設備，一些feature的定義
*/
#define VIRTIO_NET_F_CSUM 0 /* Host handles pkts w/ partial csum */
#define VIRTIO_NET_F_GUEST_CSUM 1 /* Guest handles pkts w/ partial csum */
#define VIRTIO_NET_F_MTU 3 /* Initial MTU advice. */
#define VIRTIO_NET_F_MAC 5 /* Host has given MAC address. */
#define VIRTIO_NET_F_GUEST_TSO4 7 /* Guest can handle TSOv4 in. */
#define VIRTIO_NET_F_GUEST_TSO6 8 /* Guest can handle TSOv6 in. */
#define VIRTIO_NET_F_GUEST_ECN 9 /* Guest can handle TSO[6] w/ ECN in. */
#define VIRTIO_NET_F_GUEST_UFO 10 /* Guest can handle UFO in. */
#define VIRTIO_NET_F_HOST_TSO4 11 /* Host can handle TSOv4 in. */
#define VIRTIO_NET_F_HOST_TSO6 12 /* Host can handle TSOv6 in. */
#define VIRTIO_NET_F_HOST_ECN 13 /* Host can handle TSO[6] w/ ECN in. */
#define VIRTIO_NET_F_HOST_UFO 14 /* Host can handle UFO in. */
#define VIRTIO_NET_F_MRG_RXBUF 15 /* Host can merge receive buffers. */
#define VIRTIO_NET_F_STATUS 16 /* virtio_net_config.status available */
#define VIRTIO_NET_F_CTRL_VQ 17 /* Control channel available */
#define VIRTIO_NET_F_CTRL_RX 18 /* Control channel RX mode support */
#define VIRTIO_NET_F_CTRL_VLAN 19 /* Control channel VLAN filtering */
#define VIRTIO_NET_F_CTRL_RX_EXTRA 20 /* Extra RX mode control support */
#define VIRTIO_NET_F_GUEST_ANNOUNCE 21 /* Guest can announce device on the
* network */
#define VIRTIO_NET_F_MQ 22 /* Device supports Receive Flow
* Steering */
#define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
/* Do we get callbacks when the ring is completely used, even if we've
* suppressed them?，暫未實現 */
#define VIRTIO_F_NOTIFY_ON_EMPTY 24
/* Can the device handle any descriptor layout? 用來優化對vring的使用 */
#define VIRTIO_F_ANY_LAYOUT 27
/* We support indirect buffer descriptors */
#define VIRTIO_RING_F_INDIRECT_DESC 28
#define VIRTIO_F_VERSION_1 32
#define VIRTIO_F_IOMMU_PLATFORM 33
/*
* Some VirtIO feature bits (currently bits 28 through 31) are
* reserved for the transport being used (eg. virtio_ring), the
* rest are per-device feature bits.
*/
#define VIRTIO_TRANSPORT_F_START 28
#define VIRTIO_TRANSPORT_F_END 34
/* The Guest publishes the used index for which it expects an interrupt
* at the end of the avail ring. Host should ignore the avail->flags field. */
/* The Host publishes the avail index for which it expects a kick
* at the end of the used ring. Guest should ignore the used->flags field. */
#define VIRTIO_RING_F_EVENT_IDX 29
#define VIRTIO_NET_S_LINK_UP 1 /* Link is up */
#define VIRTIO_NET_S_ANNOUNCE 2 /* Announcement is needed */
/*
* Maximum number of virtqueues per device.
* 底層驅動和設備對queue的支持
*/
#define VIRTIO_MAX_VIRTQUEUE_PAIRS 8
#define VIRTIO_MAX_VIRTQUEUES (VIRTIO_MAX_VIRTQUEUE_PAIRS * 2 + 1)
/* Common configuration */
#define VIRTIO_PCI_CAP_COMMON_CFG 1
/* Notifications */
#define VIRTIO_PCI_CAP_NOTIFY_CFG 2
/* ISR Status */
#define VIRTIO_PCI_CAP_ISR_CFG 3
/* Device specific configuration */
#define VIRTIO_PCI_CAP_DEVICE_CFG 4
/* PCI configuration access */
#define VIRTIO_PCI_CAP_PCI_CFG 5
/*第二大塊：相關數據結構，主要是對設備的配置相關*/
/* This is the PCI capability header: */
struct virtio_pci_cap {
uint8_t cap_vndr; /* Generic PCI field: PCI_CAP_ID_VNDR */
uint8_t cap_next; /* Generic PCI field: next ptr. */
uint8_t cap_len; /* Generic PCI field: capability length */
uint8_t cfg_type; /* Identifies the structure. */
uint8_t bar; /* Where to find it. */
uint8_t padding[3]; /* Pad to full dword. */
uint32_t offset; /* Offset within bar. */
uint32_t length; /* Length of the structure, in bytes. */
};
struct virtio_pci_notify_cap {
struct virtio_pci_cap cap;
uint32_t notify_off_multiplier; /* Multiplier for queue_notify_off. */
};
/* Fields in VIRTIO_PCI_CAP_COMMON_CFG: */
struct virtio_pci_common_cfg {
/* About the whole device. */
uint32_t device_feature_select; /* read-write */
uint32_t device_feature; /* read-only */
uint32_t guest_feature_select; /* read-write */
uint32_t guest_feature; /* read-write */
uint16_t msix_config; /* read-write */
uint16_t num_queues; /* read-only */
uint8_t device_status; /* read-write */
uint8_t config_generation; /* read-only */
/* About a specific virtqueue. */
uint16_t queue_select; /* read-write */
uint16_t queue_size; /* read-write, power of 2. */
uint16_t queue_msix_vector; /* read-write */
uint16_t queue_enable; /* read-write */
uint16_t queue_notify_off; /* read-only */
uint32_t queue_desc_lo; /* read-write */
uint32_t queue_desc_hi; /* read-write */
uint32_t queue_avail_lo; /* read-write */
uint32_t queue_avail_hi; /* read-write */
uint32_t queue_used_lo; /* read-write */
uint32_t queue_used_hi; /* read-write */
};
struct virtio_hw;
/*對virtio設備進行操作的函數指針結構*/
struct virtio_pci_ops {
void (*read_dev_cfg)(struct virtio_hw *hw, size_t offset,
void *dst, int len);
void (*write_dev_cfg)(struct virtio_hw *hw, size_t offset,
const void *src, int len);
void (*reset)(struct virtio_hw *hw);
uint8_t (*get_status)(struct virtio_hw *hw);
void (*set_status)(struct virtio_hw *hw, uint8_t status);
uint64_t (*get_features)(struct virtio_hw *hw);
void (*set_features)(struct virtio_hw *hw, uint64_t features);
uint8_t (*get_isr)(struct virtio_hw *hw);
uint16_t (*set_config_irq)(struct virtio_hw *hw, uint16_t vec);
uint16_t (*set_queue_irq)(struct virtio_hw *hw, struct virtqueue *vq,
uint16_t vec);
uint16_t (*get_queue_num)(struct virtio_hw *hw, uint16_t queue_id);
int (*setup_queue)(struct virtio_hw *hw, struct virtqueue *vq);
void (*del_queue)(struct virtio_hw *hw, struct virtqueue *vq);
void (*notify_queue)(struct virtio_hw *hw, struct virtqueue *vq);
};
struct virtio_net_config;
/*底層的device抽象*/
struct virtio_hw {
struct virtnet_ctl *cvq;
uint64_t req_guest_features;
uint64_t guest_features;
uint32_t max_queue_pairs;
uint16_t started;
uint16_t max_mtu;
uint16_t vtnet_hdr_size;
uint8_t vlan_strip;
uint8_t use_msix;
uint8_t modern;
uint8_t use_simple_rxtx;
uint8_t port_id;
uint8_t mac_addr[ETHER_ADDR_LEN];
uint32_t notify_off_multiplier;
uint8_t *isr;
uint16_t *notify_base;
struct virtio_pci_common_cfg *common_cfg;
struct virtio_net_config *dev_cfg;
void *virtio_user_dev;
struct virtqueue **vqs;
};
/*
* While virtio_hw is stored in shared memory, this structure stores
* some infos that may vary in the multiple process model locally.
* For example, the vtpci_ops pointer.
* 針對多核的優化，將常用訪問字段放到process的local mem里
*/
struct virtio_hw_internal {
const struct virtio_pci_ops *vtpci_ops;
struct rte_pci_ioport io;
};
#define VTPCI_OPS(hw) (virtio_hw_internal[(hw)->port_id].vtpci_ops)
#define VTPCI_IO(hw) (&virtio_hw_internal[(hw)->port_id].io)
extern struct virtio_hw_internal virtio_hw_internal[RTE_MAX_ETHPORTS];
/*
* This structure is just a reference to read
* net device specific config space; it just a chodu structure
* 這個結構體更像是為上傳抽象提供的相關組合字段
*/
struct virtio_net_config {
/* The config defining mac address (if VIRTIO_NET_F_MAC) */
uint8_t mac[ETHER_ADDR_LEN];
/* See VIRTIO_NET_F_STATUS and VIRTIO_NET_S_* above */
uint16_t status;
uint16_t max_virtqueue_pairs;
uint16_t mtu;
} __attribute__((packed));
/*
* How many bits to shift physical queue address written to QUEUE_PFN.
* 12 is historical, and due to x86 page size.
*/
#define VIRTIO_PCI_QUEUE_ADDR_SHIFT 12
/* The alignment to use between consumer and producer parts of vring. */
#define VIRTIO_PCI_VRING_ALIGN 4096
static inline int
vtpci_with_feature(struct virtio_hw *hw, uint64_t bit)
{
return (hw->guest_features & (1ULL << bit)) != 0;
}
/* 第三大塊：函數聲明，對外提供的操作接口
* Function declaration from virtio_pci.c
*/
int vtpci_init(struct rte_pci_device *dev, struct virtio_hw *hw);
void vtpci_reset(struct virtio_hw *);
void vtpci_reinit_complete(struct virtio_hw *);
uint8_t vtpci_get_status(struct virtio_hw *);
void vtpci_set_status(struct virtio_hw *, uint8_t);
uint64_t vtpci_negotiate_features(struct virtio_hw *, uint64_t);
void vtpci_write_dev_config(struct virtio_hw *, size_t, const void *, int);
void vtpci_read_dev_config(struct virtio_hw *, size_t, void *, int);
uint8_t vtpci_isr(struct virtio_hw *);
/*關於0.95和1.0的版本差異前面已經介紹，具體的ops函數需要區分兩個版本分別實現*/
extern const struct virtio_pci_ops legacy_ops;//ver 0.95
extern const struct virtio_pci_ops modern_ops;//ver 1.0
extern const struct virtio_pci_ops virtio_user_ops;
關於實現這塊沒有太多需要解釋的，主要是針對頭文件中定義的相關函數和操作進行實現，需要注意的是需要區分legacy和modern兩種版本，簡單看一個函數具體實現
//drivers\net\virio\virtio_pic.c
/*
* 初始化函數中，需要根據virtio的特性自動識別版本
* Return -1:
* if there is error mapping with VFIO/UIO.
* if port map error when driver type is KDRV_NONE.
* if whitelisted but driver type is KDRV_UNKNOWN.
* Return 1 if kernel driver is managing the device.
* Return 0 on success.
*/
int
vtpci_init(struct rte_pci_device *dev, struct virtio_hw *hw)
{
/*
* Try if we can succeed reading virtio pci caps, which exists
* only on modern pci device. If failed, we fallback to legacy
* virtio handling.
*/
if (virtio_read_caps(dev, hw) == 0) {
PMD_INIT_LOG(INFO, "modern virtio pci detected.");
virtio_hw_internal[hw->port_id].vtpci_ops = &modern_ops;
hw->modern = 1;
return 0;
}
/*如果失敗，就嘗試綁定legacy操作*/
PMD_INIT_LOG(INFO, "trying with legacy virtio pci.");
if (rte_pci_ioport_map(dev, 0, VTPCI_IO(hw)) < 0) {
//跳過內核管理的virtio
if (dev->kdrv == RTE_KDRV_UNKNOWN &&
(!dev->device.devargs ||
dev->device.devargs->type !=
RTE_DEVTYPE_WHITELISTED_PCI)) {
PMD_INIT_LOG(INFO,
"skip kernel managed virtio device.");
return 1;
}
return -1;
}
virtio_hw_internal[hw->port_id].vtpci_ops = &legacy_ops;
hw->modern = 0;
return 0;
}
第二層抽象
本層中比較重要的數據結構是vring,virtqueue:
//drivers\net\virtio\virtio_ring.h
/* 每個描述符代表guest側的一個數據緩沖區，供guest和host傳遞數據。
* 如果要傳遞的數據大於一個desc的容量，可以包含多個desc，由next串起來*/
struct vring_desc {
uint64_t addr; /* Address (guest-physical). */
uint32_t len; /* Length. */
uint16_t flags; /* The flags as indicated above. */
uint16_t next; /* We chain unused descriptors via this. */
};
/* id is a 16bit index. uint32_t is used here for ids for padding reasons. */
struct vring_used_elem {
/* Index of start of used descriptor chain. */
uint32_t id;
/* Total length of the descriptor chain which was written to. */
uint32_t len;
};
/* vring的布局：num個vring_desc + available ring size + pad + used ring size
* The standard layout for the ring is a continuous chunk of memory which
* looks like this. We assume num is a power of 2.
* NOTE: for VirtIO PCI, align is 4096.
*/
struct vring {
// The actual descriptors (16 bytes each)
struct vring_desc desc[num];
/*可用環表，由驅動提供(寫入)，設備使用(讀取)。*/
__u16 avail_flags;
__u16 avail_idx;
__u16 available[num];
__u16 used_event_idx;
// Padding to the next align boundary.
char pad[];
/*已用環表，由設備提供(寫入)，驅動使用（讀取）*/
__u16 used_flags;
__u16 used_idx;
struct vring_used_elem used[num];
__u16 avail_event_idx;
};
/*vring size的計算公式*/
vring_size(unsigned int num, unsigned long align)
{
size_t size;
size = num * sizeof(struct vring_desc);
size += sizeof(struct vring_avail) + (num * sizeof(uint16_t));
size = RTE_ALIGN_CEIL(size, align);
size += sizeof(struct vring_used) +
(num * sizeof(struct vring_used_elem));
return size;
}
關於available ring和used ring中的flags字段，需要特別解釋下：
- available ring flag：該環中的desc可能是可讀，也可能是可寫的。可寫的是指驅動提供給設備的desc，供設備寫入后還需要傳回給驅動；可讀的則是用於發送驅動的數據到設備中。flag可以用來標示設備在使用了desc后是否發送中斷給驅動。
- used ring flag:表示已用環表的一些屬性，包括是否需要驅動在回收了已用環表中的表項后發送提醒給設備。
//drivers\net\virtio\virtqueue.h
struct virtqueue {
struct virtio_hw *hw; /**< virtio_hw structure pointer. */
struct vring vq_ring; /**< vring keeping desc, used and avail */
/**
* Last consumed descriptor in the used table,
* trails vq_ring.used->idx.
*/
uint16_t vq_used_cons_idx;
uint16_t vq_nentries; /**< vring desc numbers */
uint16_t vq_free_cnt; /**< num of desc available */
uint16_t vq_avail_idx; /**< sync until needed */
uint16_t vq_free_thresh; /**< free threshold */
void *vq_ring_virt_mem; /**< linear address of vring*/
unsigned int vq_ring_size;
/*用途，是收包，發包還是控制通道？*/
union {
struct virtnet_rx rxq;
struct virtnet_tx txq;
struct virtnet_ctl cq;
};
phys_addr_t vq_ring_mem; /**< physical address of vring,
* or virtual address for virtio_user. */
/**
* Head of the free chain in the descriptor table. If
* there are no free descriptors, this will be set to
* VQ_RING_DESC_CHAIN_END.
*/
uint16_t vq_desc_head_idx;
uint16_t vq_desc_tail_idx;
uint16_t vq_queue_index; /**< PCI queue index */
uint16_t offset; /**< relative offset to obtain addr in mbuf，具體使用可以參見宏VIRTIO_MBUF_ADDR*/
uint16_t *notify_addr;
struct rte_mbuf **sw_ring; /**< RX software ring. */
struct vq_desc_extra vq_descx[0];
};
//todo:對virtqueue的使用接口
每個設備擁有多個 virtqueue 用於大塊數據的傳輸。virtqueue 是一個簡單的隊列（其中包括vring），guest 把 buffers 插入其中，每個 buffer 都是一個分散-聚集數組。virtqueue 的數目根據設備的不同而不同，例如network 設備通常有 2 個 virtqueue,一個用於發送數據包，一個用於接收數據包。
第三層抽象
本層實現virtio設備以及對設備的各種操作函數。對virtio設備的初始化配置以及特性設置主要集中在virtio_ethdev.c中實現。
這一步的實現代碼比較多，僅羅列一些比較重要的，感興趣的可深入閱讀相關接口。
/*驅動初始化virtio設備
* 重新設置rte_eth_dev結構及特性，最大化共用基礎結構，而沒有重新定義一個virtio dev structure
* 在這個接口里還會和host進行feature的協商，為device申請分配virtqueue，配置中斷等等
*/
eth_virtio_dev_init(struct rte_eth_dev *eth_dev);
/*為device分配virtqueue，首先獲取支持的最大隊列，再對每個隊列執行初始化*/
virtio_alloc_queues(struct rte_eth_dev *dev);
/*具體的一個隊列初始化函數，在這個函數里會區分隊列類型，是收包，發包還是控制隊列*/
static int virtio_init_queue(struct rte_eth_dev *dev, uint16_t vtpci_queue_idx)
/*另外比較重要的是，通過以上初始話過程，會賦值設備的dev_ops,rx_pkt_burst,tx_pkt_burst*/
eth_dev->dev_ops = &virtio_eth_dev_ops;
eth_dev->tx_pkt_burst = &virtio_xmit_pkts;
rx_func_get(struct rte_eth_dev *eth_dev)
{
struct virtio_hw *hw = eth_dev->data->dev_private;
if (vtpci_with_feature(hw, VIRTIO_NET_F_MRG_RXBUF))
eth_dev->rx_pkt_burst = &virtio_recv_mergeable_pkts;//如果打開mergeable特性的化
else
eth_dev->rx_pkt_burst = &virtio_recv_pkts;//普通的收包函數
}
設備初始化好后，virtio設備的使用主要包括兩部分：驅動通過描述符列表和可用環表提供數據緩沖區給設備，設備使用數據緩沖區再通過已用環表還給驅動。以網卡為例：網絡設備一般有兩個vq：發包隊列和接收隊列。驅動添加要發送的包到發送隊列，然后設備讀取並發送完成后，驅動再釋放這些包。反方向，設備將包寫入到接收隊列中，驅動則在已用環表中處理這些包。
先看收包函數：
//drivers\net\virtio\virtio_rxtx.c
uint16_t
virtio_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts)
{
...
num = (uint16_t)(likely(nb_used <= nb_pkts) ? nb_used : nb_pkts);
num = (uint16_t)(likely(num <= VIRTIO_MBUF_BURST_SZ) ? num : VIRTIO_MBUF_BURST_SZ);
if (likely(num > DESC_PER_CACHELINE))
num = num - ((vq->vq_used_cons_idx + num) % DESC_PER_CACHELINE);
/*驅動一次性從收包隊列中獲取num個報文，實際上是讀取已用環表獲取描述符，
*讀取完成后需要釋放desc到free chain中
*/
num = virtqueue_dequeue_burst_rx(vq, rcv_pkts, len, num);
PMD_RX_LOG(DEBUG, "used:%d dequeue:%d", nb_used, num);
/*將前面讀出來的報文賦值到二級指針rx_pkts中*/
for (i = 0; i < num ; i++) {
rxm = rcv_pkts[i];
PMD_RX_LOG(DEBUG, "packet len:%d", len[i]);
if (unlikely(len[i] < hdr_size + ETHER_HDR_LEN)) {
PMD_RX_LOG(ERR, "Packet drop");
nb_enqueued++;
virtio_discard_rxbuf(vq, rxm);
rxvq->stats.errors++;
continue;
}
rxm->port = rxvq->port_id;
rxm->data_off = RTE_PKTMBUF_HEADROOM;
rxm->ol_flags = 0;
rxm->vlan_tci = 0;
rxm->pkt_len = (uint32_t)(len[i] - hdr_size);
rxm->data_len = (uint16_t)(len[i] - hdr_size);
hdr = (struct virtio_net_hdr *)((char *)rxm->buf_addr +
RTE_PKTMBUF_HEADROOM - hdr_size);
if (hw->vlan_strip)
rte_vlan_strip(rxm);
if (offload && virtio_rx_offload(rxm, hdr) < 0) {
virtio_discard_rxbuf(vq, rxm);
rxvq->stats.errors++;
continue;
}
VIRTIO_DUMP_PACKET(rxm, rxm->data_len);
/*把報文dump出來到rx_pkts*/
rx_pkts[nb_rx++] = rxm;
rxvq->stats.bytes += rxm->pkt_len;
virtio_update_packet_stats(&rxvq->stats, rxm);
}
.....
/* 重新對used descriptor分配mbuf，並插入到可用隊列中 */
error = ENOSPC;
while (likely(!virtqueue_full(vq))) {
new_mbuf = rte_mbuf_raw_alloc(rxvq->mpool);
if (unlikely(new_mbuf == NULL)) {
struct rte_eth_dev *dev
= &rte_eth_devices[rxvq->port_id];
dev->data->rx_mbuf_alloc_failed++;
break;
}
error = virtqueue_enqueue_recv_refill(vq, new_mbuf);
if (unlikely(error)) {
rte_pktmbuf_free(new_mbuf);
break;
}
nb_enqueued++;
}
/*可用隊列更新后，要通知host端設備*/
if (likely(nb_enqueued)) {
vq_update_avail_idx(vq);
if (unlikely(virtqueue_kick_prepare(vq))) {
virtqueue_notify(vq);
PMD_RX_LOG(DEBUG, "Notified");
}
}
return nb_rx;
}
再看發包函數：
virtio_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
{
......
virtio_rmb();//加鎖
/*如果已用環表空間不足，將已經傳輸完成的釋放掉*/
if (likely(nb_used > vq->vq_nentries - vq->vq_free_thresh))
virtio_xmit_cleanup(vq, nb_used);
for (nb_tx = 0; nb_tx < nb_pkts; nb_tx++) {
struct rte_mbuf *txm = tx_pkts[nb_tx];
int can_push = 0, use_indirect = 0, slots, need;
...
/* 實際的發包函數，將txm中的數據通過txvq發送出去 */
virtqueue_enqueue_xmit(txvq, txm, slots, use_indirect, can_push);
txvq->stats.bytes += txm->pkt_len;
virtio_update_packet_stats(&txvq->stats, txm);
}
txvq->stats.packets += nb_tx;
/*通知host*/
if (likely(nb_tx)) {
vq_update_avail_idx(vq);
if (unlikely(virtqueue_kick_prepare(vq))) {
virtqueue_notify(vq);
PMD_TX_LOG(DEBUG, "Notified backend after xmit");
}
}
return nb_tx;
}
virtqueue_enqueue_xmit(struct virtnet_tx *txvq, struct rte_mbuf *cookie,
uint16_t needed, int use_indirect, int can_push)
{
....
do {
start_dp[idx].addr = VIRTIO_MBUF_DATA_DMA_ADDR(cookie, vq);
start_dp[idx].len = cookie->data_len;
start_dp[idx].flags = cookie->next ? VRING_DESC_F_NEXT : 0;
idx = start_dp[idx].next;
} while ((cookie = cookie->next) != NULL);
if (use_indirect)
idx = vq->vq_ring.desc[head_idx].next;
vq->vq_desc_head_idx = idx;
if (vq->vq_desc_head_idx == VQ_RING_DESC_CHAIN_END)
vq->vq_desc_tail_idx = idx;
vq->vq_free_cnt = (uint16_t)(vq->vq_free_cnt - needed);
//把cookie內容放入desc中，更新可用環表
vq_update_avail_ring(vq, head_idx);
}
vhost
vhost就是virtio-net的后端驅動，關於dpdk vhost這部分資料總結和介紹，可以參考之前整理的文檔：
SR-IOV
SR-IOV 是PCI-SIG的一個IOV的規范，目的是提供一種標准規范，通過為虛擬機提供獨立的內存空間，中斷，DMA流，來繞過VMM實現數據移動。SR-IOV 架構被設計用於將單個設備通過支持多個VF，並減少硬件的開銷。
SR-IOV 引入了兩種類型：
- PF： 包含完整的PCIe 功能，包括SR-IOV的擴展能力，其包含用於配置和管理 SR-IOV 的功能。可以使用 PF 來配置和控制 PCIe 設備，且 PF 具有將數據移入和移出設備的完整功能。
- FV： 包含輕量級的PCIe 功能。其包含數據移動所需的所有資源，且具有一套經過仔細精簡的配置資源集。
要實現SRIOV功能，前提條件就是網卡硬件首先要支持SRIOV，其次主板要支持intel VT-d技術。
SR-IOV的結構圖實現如下：
圖7 SR-IOV架構圖
以上圖為例逐個解釋關鍵詞：
- PF就是物理網卡所支持的一項PCI功能，PF可以擴展出若干個VF
- VF是支持SRIOV的物理網卡所虛擬出的一個“網卡”或者說虛出來的一個實例，它會以一個獨立網卡的形式呈現出來，每一個VF有它自己獨享的PCI配置區域，並且可能與其他VF共享着同一個物理資源（公用同一個物理網口）
- PF miniport driver即PF驅動是工作於Hyper-V虛擬化平台父區域的，並在VF之前最先加載
- VF miniport driver即VF驅動是工作於Hyper-V虛擬化平台子區域的，即guestOS；需要注意的是，VF及PF之間是隔離的，任何經由VF驅動或所執行的結果都不會影響到其他的VF或PF
- Network Interface Card即物理網卡，在啟用SRIOV之后會生成若干vport，物理NIC所要做的就是轉發physical port與vport之間的流量
- physical port顧名思義就是物理網口，在SRIOV場景中physical port充當一個面向對外的網絡媒介
- VPort是個抽象出來的接口，類似於物理網口，它們被映射給每一個VF或者PF，供parentOS或guestOS來使用
啟用SRIOV之后，物理NIC將通過VF與虛擬機（VF driver）進行數據交互，反之亦然。那么這樣一來即可跳過中間的虛擬化堆棧（即VMM層），以達到近乎於純物理環境的性能；這一點也是SRIOV最大的價值所在。
關於更詳細的介紹資料和實驗數據對比，可以參考這里和這里
關於dpdk使用SR-IOV的參考資料在這里。
摘自上面的資料，使用SR_IOV技術和純物理機，以及用戶態的ovs性能對比如下：
圖8：不同技術的性能對比
比較典型的IMIX流量中小包占比會在50%~60%之間，從上表可以看到SR-IOV的測試數據中小包處理能力在70%左右，這就表明該技術在實際的使用環境中能夠應對絕大多數場景；而OVS在此方面的優化還需要繼續努力。
另外關於dpdk使用SR-IOV的配置，可以參考如下：
熱遷移相關
從上面的介紹了解，要使用DPDK技術，在VM中可以使用virtio驅動，也可以使用硬件網卡提供的SR-IOV VF來支持。對於熱遷移來說，就需要針對兩種驅動單獨考慮。
如何使用
DPDK關於使用兩種驅動的測試用例在官網有提供，可以參考：
- Live Migration of VM with SR-IOV VF，由於這種驅動是硬件提供switch來完成報文到VF的分發，很難去感知VM的遷移，因此需要借助其他技術來實現遷移，文中提到的使用bond口就是當前的實現方案
- Live Migration of Vm with Virtio on host running vhost-user，這種驅動中使用的vswitch功能，因此還是比較好實現VM的遷移的。
結合ovs的測試方法，可以參考這里。
代碼相關支持
對代碼的修改主要是由以下patch來完成：
- Patch 1 handles VHOST_USER_SET_LOG_BASE, which tells us where
the dirty memory bitmap is.
//通過mmap將要遷移的dirty memory設置成shared狀態，可供對端讀寫
static int
vhost_user_set_log_base(struct virtio_net *dev, struct VhostUserMsg *msg)
{
int fd = msg->fds[0];
uint64_t size, off;
void *addr;
if (fd < 0) {
RTE_LOG(ERR, VHOST_CONFIG, "invalid log fd: %d\n", fd);
return -1;
}
if (msg->size != sizeof(VhostUserLog)) {
RTE_LOG(ERR, VHOST_CONFIG,
"invalid log base msg size: %"PRId32" != %d\n",
msg->size, (int)sizeof(VhostUserLog));
return -1;
}
size = msg->payload.log.mmap_size;
off = msg->payload.log.mmap_offset;
RTE_LOG(INFO, VHOST_CONFIG,
"log mmap size: %"PRId64", offset: %"PRId64"\n",
size, off);
/*
* mmap from 0 to workaround a hugepage mmap bug: mmap will
* fail when offset is not page size aligned.
*/
addr = mmap(0, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
close(fd);
if (addr == MAP_FAILED) {
RTE_LOG(ERR, VHOST_CONFIG, "mmap log base failed!\n");
return -1;
}
/*
* Free previously mapped log memory on occasionally
* multiple VHOST_USER_SET_LOG_BASE.
*/
if (dev->log_addr) {
munmap((void *)(uintptr_t)dev->log_addr, dev->log_size);
}
dev->log_addr = (uint64_t)(uintptr_t)addr;
dev->log_base = dev->log_addr + off;
dev->log_size = size;
return 0;
}
- Patch 2 introduces a vhost_log_write() helper function to log
pages we are gonna change. 對端vm通過同步這些page即可完成狀態的遷移。
//rte_vhost_log_write->vhost_log_write
static inline void __attribute__((always_inline))
vhost_log_write(struct virtio_net *dev, uint64_t addr, uint64_t len)
{
uint64_t page;
if (likely(((dev->features & (1ULL << VHOST_F_LOG_ALL)) == 0) ||
!dev->log_base || !len))
return;
if (unlikely(dev->log_size <= ((addr + len - 1) / VHOST_LOG_PAGE / 8)))
return;
/* To make sure guest memory updates are committed before logging */
rte_smp_wmb();
page = addr / VHOST_LOG_PAGE;
while (page * VHOST_LOG_PAGE < addr + len) {
vhost_log_page((uint8_t *)(uintptr_t)dev->log_base, page);
page += 1;
}
}
static inline void __attribute__((always_inline))
vhost_log_page(uint8_t *log_base, uint64_t page)
{
log_base[page / 8] |= 1 << (page % 8);
}
- Patch 3 logs changes we made to used vring.
//rte_vhost_log_used_vring->vhost_log_used_vring
static inline void __attribute__((always_inline))
vhost_log_used_vring(struct virtio_net *dev, struct vhost_virtqueue *vq,
uint64_t offset, uint64_t len)
{
vhost_log_write(dev, vq->log_guest_addr + offset, len);
}
- Patch 4 sets log_shmfd protocol feature bit, which actually
enables the vhost-user live migration support.
#define VHOST_USER_PROTOCOL_F_LOG_SHMFD 1
#define VHOST_USER_PROTOCOL_FEATURES ((1ULL << VHOST_USER_PROTOCOL_F_MQ) | \
(1ULL << VHOST_USER_PROTOCOL_F_LOG_SHMFD) |\
(1ULL << VHOST_USER_PROTOCOL_F_RARP) | \
(0ULL << VHOST_USER_PROTOCOL_F_REPLY_ACK) | \
(1ULL << VHOST_USER_PROTOCOL_F_NET_MTU))
RARP報文
構造免費ARP報文RARP來解決vm遷移后的丟包問題
研究拓
作者：分享放大價值
鏈接：http://www.jianshu.com/p/08ba1ea13729
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。