KVM虛擬化原理中的網(wǎng)絡IO虛擬化是怎樣的
KVM 虛擬化原理中的網(wǎng)絡IO虛擬化是怎樣的，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。
成都創(chuàng)新互聯(lián)專注于玉林企業(yè)網(wǎng)站建設,響應式網(wǎng)站開發(fā),商城建設。玉林網(wǎng)站建設公司,為玉林等地區(qū)提供建站服務。全流程按需搭建網(wǎng)站，專業(yè)設計，全程項目跟蹤，成都創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務
IO 虛擬化簡介
前面的文章介紹了KVM的啟動過程，CPU虛擬化，內存虛擬化原理。作為一個完整的風諾依曼計算機系統(tǒng)，必然有輸入計算輸出這個步驟。傳統(tǒng)的IO包括了網(wǎng)絡設備IO，塊設備IO，字符設備IO等等，在KVM虛擬化原理探究里面，我們最主要介紹網(wǎng)絡設備IO和塊設備IO，其實他們的原理都很像，但是在虛擬化層又分化開了，這也是為什么網(wǎng)絡設備IO虛擬化和塊設備IO虛擬化要分開講的原因。這一章介紹一下網(wǎng)絡設備IO虛擬化，下一章介紹塊設備IO虛擬化。
傳統(tǒng)的網(wǎng)絡IO流程
這里的傳統(tǒng)并不是真的傳統(tǒng)，而是介紹一下在非虛擬化環(huán)境下的網(wǎng)絡設備IO流程。我們平常所使用的Linux版本，比如Debian或者CentOS等都是標準的Linux TCP/IP協(xié)議棧，協(xié)議棧底層提供了driver抽象層來適配不同的網(wǎng)卡，在虛擬化中最重要的是設備的虛擬化，但是了解整個網(wǎng)絡IO流程后去看待虛擬化就會更加容易理解了。
標準的TCP/IP結構
在用戶層，我們通過socket與Kernel做交互，包括創(chuàng)建端口，數(shù)據(jù)的接收發(fā)送等操作。
在Kernel層，TCP/IP協(xié)議棧負責將我們的socket數(shù)據(jù)封裝到TCP或者UDP包中，然后進入IP層，加入IP地址端口信息等，進入數(shù)據(jù)鏈路層，加入Mac地址等信息后，通過驅動寫入到網(wǎng)卡，網(wǎng)卡再把數(shù)據(jù)發(fā)送出去。如下圖所示，比較主觀的圖。
在Linux的TCP/IP協(xié)議棧中，每個數(shù)據(jù)包是有內核的skb_buff結構描述的，如下圖所示，socket發(fā)送數(shù)據(jù)包的時候后，進入內核，內核從skb_buff的池中分配一個skb_buff用來承載數(shù)據(jù)流量。
發(fā)送數(shù)據(jù)和接收數(shù)據(jù)驅動層都采用DMA模式，驅動加載時候會為網(wǎng)卡映射內存并設置描述狀態(tài)(寄存器中），也就是內存的起始位，長度，剩余大小等等。發(fā)送時候將數(shù)據(jù)放到映射的內存中，然后設置網(wǎng)卡寄存器產(chǎn)生一個中斷，告訴網(wǎng)卡有數(shù)據(jù)，網(wǎng)卡收到中斷后處理對應的內存中的數(shù)據(jù)，處理完后向CPU產(chǎn)生一個中斷告訴CPU數(shù)據(jù)發(fā)送完成，CPU中斷處理過程中向上層driver通知數(shù)據(jù)發(fā)送完成，driver再依次向上層返回。在這個過程中對于driver來說，發(fā)送是同步的。接收數(shù)據(jù)的流程和發(fā)送數(shù)據(jù)幾乎一致，這里就不細說了。DMA的模式對后面的IO虛擬化來說很重要。
KVM 網(wǎng)絡IO虛擬化
準確來說，KVM只提供了一些基本的CPU和內存的虛擬化方案，真正的IO實現(xiàn)都由qemu-kvm來完成，只不過我們在介紹KVM的文章里都默認qemu-kvm和KVM為一個體系，就沒有分的那么仔細了。實際上網(wǎng)絡IO虛擬化都是由qemu-kvm來完成的。
KVM 全虛擬化IO
還記得我們第一章節(jié)的demo里面，我們的“鏡像”調用了 out 指令產(chǎn)生了一個IO操作，然后因為此操作為敏感的設備訪問類型的操作，不能在VMX non-root 模式下執(zhí)行，于是VM exits，模擬器接管了這個IO操作。
switch (kvm->vcpus->kvm_run->exit_reason) {
case KVM_EXIT_UNKNOWN:
printf("KVM_EXIT_UNKNOWN\n");
break;
// 虛擬機執(zhí)行了IO操作，虛擬機模式下的CPU會暫停虛擬機并
// 把執(zhí)行權交給emulator
case KVM_EXIT_IO:
printf("KVM_EXIT_IO\n");
printf("out port: %d, data: %d\n",
kvm->vcpus->kvm_run->io.port,
*(int *)((char *)(kvm->vcpus->kvm_run) + kvm->vcpus->kvm_run->io.data_offset)
);
break;
...虛擬機退出并得知原因為 KVM_EXIT_IO，模擬器得知由于設備產(chǎn)生了IO操作并退出，于是獲取這個IO操作并打印出數(shù)據(jù)。這里其實我們就最小化的模擬了一個虛擬IO的過程，由模擬器接管這個IO。
在qemu-kvm全虛擬化的IO過程中，其實原理也是一樣，KVM捕獲IO中斷，由qemu-kvm接管這個IO，由于采用了DMA映射，qemu-kvm在啟動時候會注冊設備的mmio信息，以便能獲取到DMA設備的映射內存和控制信息。
static int pci_e1000_init(PCIDevice *pci_dev)
{
e1000_mmio_setup(d);
// 為PCI設備設置 mmio 空間
pci_register_bar(&d->dev, 0, PCI_BASE_ADDRESS_SPACE_MEMORY, &d->mmio);
pci_register_bar(&d->dev, 1, PCI_BASE_ADDRESS_SPACE_IO, &d->io);
d->nic = qemu_new_nic(&net_e1000_info, &d->conf, object_get_typename(OBJECT(d)), d->dev.qdev.id, d);
add_boot_device_path(d->conf.bootindex, &pci_dev->qdev, "/ethernet-phy@0");
}對于PCI設備來說，當設備與CPU之間通過映射了一段連續(xù)的物理內存后，CPU對PCI設備的訪問只需要像訪問內存一樣訪問既可以。IO設備通常有兩種模式，一種是port模式，一種是MMIO模式，前者就是我們demo里面的in/out指令，后者就是PCI設備的DMA訪問方式，兩種方式的操作都能被KVM捕獲。
于是qemu-kvm將此操作代替Guest完成后并執(zhí)行相應的“回調”，也就是向vCPU產(chǎn)生中斷告訴IO完成并返回Guest繼續(xù)執(zhí)行。vCPU中斷和CPU中斷一樣，設置相應的寄存器后中斷便會觸發(fā)。
在全虛擬化環(huán)境下，Guest中的IO都由qemu-kvm接管，在Guest中看到的一個網(wǎng)卡設備并不是真正的一塊網(wǎng)卡，而是由物理機產(chǎn)生的一個tap設備。知識在驅動注冊的時候將一些tap設備所支持的特性加入到了Guest的驅動注冊信息里面，所以在Guest中看到有網(wǎng)絡設備。
如上圖所示，qemu接管了來自Guest的IO操作，真實的場景肯定是需要將數(shù)據(jù)再次發(fā)送出去的，而不是像demo一樣打印出來，在Guest中的數(shù)據(jù)包二層封裝的Mac地址后，qemu層不需要對數(shù)據(jù)進行拆開再解析，而只需要將數(shù)據(jù)寫入到tap設備，tap設備和bridge之間交互完成后，由bridge直接發(fā)送到網(wǎng)卡，bridge（其實NIC綁定到了Bridge）開啟了混雜模式，可以將所有請求都接收或者發(fā)送出去。
以下來自這篇文章的引用
當一個 TAP 設備被創(chuàng)建時，在 Linux 設備文件目錄下將會生成一個對應 char 設備，用戶程序可以像打開普通文件一樣打開這個文件進行讀寫。當執(zhí)行 write()操作時，數(shù)據(jù)進入 TAP 設備，此時對于 Linux 網(wǎng)絡層來說，相當于 TAP 設備收到了一包數(shù)據(jù)，請求內核接受它，如同普通的物理網(wǎng)卡從外界收到一包數(shù)據(jù)一樣，不同的是其實數(shù)據(jù)來自 Linux 上的一個用戶程序。Linux 收到此數(shù)據(jù)后將根據(jù)網(wǎng)絡配置進行后續(xù)處理，從而完成了用戶程序向 Linux 內核網(wǎng)絡層注入數(shù)據(jù)的功能。當用戶程序執(zhí)行 read()請求時，相當于向內核查詢 TAP 設備上是否有需要被發(fā)送出去的數(shù)據(jù)，有的話取出到用戶程序里，完成 TAP 設備的發(fā)送數(shù)據(jù)功能。針對 TAP 設備的一個形象的比喻是：使用 TAP 設備的應用程序相當于另外一臺計算機，TAP 設備是本機的一個網(wǎng)卡，他們之間相互連接。應用程序通過 read()/write()操作，和本機網(wǎng)絡核心進行通訊。
類似這樣的操作
fd = open("/dev/tap", XXX)
write(fd, buf, 1024);
read(fd, buf, 1024);bridge可能是一個Linux bridge，也可能是一個OVS（Open virtual switch），在涉及到網(wǎng)絡虛擬化的時候，通常需要利用到bridge提供的VLAN tag功能。
以上就是KVM的網(wǎng)絡全虛擬化IO流程了，我們也可以看到這個流程的不足，比如說當網(wǎng)絡流量很大的時候，會產(chǎn)生過多的VM的切換，同時產(chǎn)生過多的數(shù)據(jù)copy操作，我們知道copy是很浪費CPU時鐘周期的。于是qemu-kvm在發(fā)展的過程中，實現(xiàn)了virtio驅動。
KVM Virtio 驅動
基于 Virtio 的虛擬化也叫作半虛擬化，因為要求在Guest中加入virtio驅動，也就意味著Guest知道了自己運行于虛擬環(huán)境了。
vhost-net 繞過了 QEMU 直接在Guest的front-end和backend之間通信，減少了數(shù)據(jù)的拷貝，特別是減少了用戶態(tài)到內核態(tài)的拷貝。性能得到大大加強，就吞吐量來說，vhost-net基本能夠跑滿一臺物理機的帶寬。
vhost-net需要內核支持，Redhat 6.1 后開始支持，默認狀態(tài)下是開啟的。
KVM的網(wǎng)絡設備IO虛擬化經(jīng)過了全虛擬化->virtio->vhost-net的進化，性能越來越接近真實物理網(wǎng)卡，但是在小包處理方面任然存在差距，不過已經(jīng)不是一個系統(tǒng)的瓶頸了，可以看到KVM在經(jīng)過了這多年的發(fā)展后，性能也是越發(fā)的強勁，這也是他領先于其他虛擬化的重要原因之一。
看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝您對創(chuàng)新互聯(lián)的支持。
分享標題：KVM虛擬化原理中的網(wǎng)絡IO虛擬化是怎樣的
文章路徑：http://bm7419.com/article32/jjejsc.html
成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供全網(wǎng)營銷推廣、網(wǎng)站收錄、響應式網(wǎng)站、移動網(wǎng)站建設、靜態(tài)網(wǎng)站、品牌網(wǎng)站設計
聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)
