計算虛擬化根據作業系統所組成的設備型別包含 CPU 虛擬化、記憶體虛擬化和 IO 虛擬化，
先簡單介紹一下 KVM再說一下cpu、記憶體和IO是怎樣虛擬化的，
KVM
KVM，全稱是 Kernel-based Virtual Machine（基于內核的虛擬機），是一種典型 II 型全虛擬化，它之所以叫做基于內核的虛擬機，是因為 KVM 本身是一個 Linux 內核模塊，當一個安裝有 Linux 系統的物理機安裝了這個模塊以后，就變成了 Hypervisor（VMM），而且還不會影響原先在該 Linux 上運行的其它應用程式，而且每個虛擬機都是行程，可以直接使用 kill 命令殺掉， 一個普通的 Linux 安裝了 KVM 模塊以后，會增加三種運行模式：
User Mode：用戶空間，此模式下運行的主要是 QEMU，它用來為虛擬機模擬執行 I/O 類的操作請求；
Kernel Mode：內核空間，在此模式下可以真正的操作硬體，當 Guest OS 執行 I/O 類操作或特權指令操作時需要向用戶模式提交請求，然后由用戶模式再次發起 硬體操作請求給內核模式從而真正操作硬體，
KVM 體系一般包括三部分：KVM 內核模塊、QEMU 和管理工具，其中 KVM 內核模塊和 QEMU 是 KVM 的核心組件，具體如下圖所示，
除了 KVM，其它的虛擬化產品基本幾乎都是類似的架構，
KVM 內核模塊是 KVM 虛擬機的核心部分，其主要功能是初始化 CPU 硬體，打開虛擬化模 式，然后將 Geust Machine 運行在虛擬機模式下，并對虛擬客戶機的運行提供一定的支持，
KVM 模塊中，實作虛擬化功能的是 kvm.ko，還包括一個和處理器強相關的模塊如 kvm-intel.ko 或 kvm-amd.ko，KVM 本身不能實作任何模擬功能，它僅僅是提供了一個/dev/kvm 介面，這個介面可被宿主機用來主要負責 vCPU 的創建、虛擬記憶體的地址空間分配、vCPU 寄存 器的讀寫以及 vCPU 的運行，所以 kvm.ko 只提供了 CPU 和記憶體的虛擬化，但是一個虛擬機除 了 CPU 和記憶體外，還需要網卡、硬碟等其它的 IO 設備，這時候就需要另外一個組件——
QEMU 了，KVM 核心模塊和 QEMU 在一起才能構成一個完整的虛擬化技術，
其實 QEMU 原本不是 KVM 的一部分，它是一個通用的開源的使用純軟體來實作的虛擬 化的模擬器，Guest OS 以為自己在和硬體進行互動，其實真正互動的是 QEMU，然后在通過 QEMU 去和硬體互動，這就意味著所有的和硬體互動都需要經過 QEMU，所以使用 QEMU 進 行模擬的性能比較低，QMEU 本身可以模擬 CPU 和記憶體，在 KVM 中，只使用 QEMU 來模擬 IO 設備，KVM 的開發者將其進行了改造，形成了 QEMU-KVM，
在 QEMU-KVM 中，KVM 運行在內核空間，QEMU 運行在用戶空間，Guest OS 下發指令 的時候，和 CPU 和記憶體相關的指令會通過 QEMU-KVM 中的/ioctl 呼叫 /dev/kvm，從而將這 部分指令的部分交給內核模塊來做，從 QEMU 的角度來看，這樣做也可以提高虛擬化加速，其 它的 IO 操作則由 QEMU-KVM 中的 QEMU 部分實作，KVM 加上 QEMU 后就是完整意義上的 虛擬化，
除了進行各種設備的虛擬化外，QEMU-KVM 還提供了原生的工具可以對虛擬機進行創建、 修改和洗掉等管理，然而，Libvirt 是目前使用最為廣泛的對 KVM 虛擬機進行管理的工具和 API，
Libvirt 也是一個開源專案，它是一個非常強大的管理工具，被管理的虛擬化平臺可以是 KVM，也可以是 Xen 或者 VMware 以及 Hyper-V 等等，Libvirt 是一臺由 C 語言開發的 API， 其它的語言，比如 Java、Python、Perl 等，可以通過呼叫 Libvirt 的 API 去管理各個虛擬化平 臺，Libvirt 被很多的應用用到，除了自己本身的 virsh 命令集外，Virt-manager、Virt- viewer、Virt-install 都可以通過 Libvirt 管理 KVM 虛擬機，
在講 CPU 虛擬化前，我們先簡單介紹一下 CPU 的分級保護域，在這種保護模式中，CPU 被分成 4 個環——Ring0、Ring1、Ring2 和 Ring3，Ring0 的權限最高，Ring1 次之，Ring2 再次之，Ring3 最低，Ring0 的權限可以直接操作硬體，一般只有作業系統和驅動會允許擁有此 權限，Ring3 的權限最低，所有的程式都可以擁有此權限，為了保護計算機，一些危險的指令只 能由作業系統執行，防止一些惡意軟體隨意地呼叫硬體資源，比如某個程式需要開啟攝像頭就必須向 Ring0 的驅動程式請求開啟，否則會被拒絕此類操作，
在普通主機上的作業系統所發出的指令分為兩種型別：特權指令和普通指令，
- 特權指令：是指用于操作和管理關鍵系統資源的指令，這些指令只有在最高特權級 上才能夠運行，即必須在 Ring 0 級別上才能運行的指令，
- 普通指令：與特權指令相對的是普通指令，這些指令在 CPU 普通權限級別上就能夠 運行，即在 Ring 3 級別上就可以運行的指令，
在虛擬化環境下，還有一種特殊指令被稱為敏感指令，敏感指令是指修改虛擬機的運行模式或宿主機狀態的指令，也就是說是將 Guest OS 中原本需要在 Ring 0 模式下才能運行的特權指 令剝奪特權后，交給 VMM 所執行的指令，
虛擬化技術首先出現在 IBM 大型機上，大型機如何解決 CPU 共享問題的呢？首先我們先了 解一下大型機的 CPU 虛擬化方式，大型機 CPU 虛擬化采取的是“特權解除(Privilege deprivileging)”和“陷入模擬(Trap-and-Emulation)”方法，這種方法也被稱為經典虛擬化方 式，它的基本原理是，將 Guest OS 運行在非特權級（即特權解除），而將 VMM 運行于最高特 權級（即完全控制系統資源），
這個時候就出現了一個問題：如果虛擬機 Guest OS 發出特權操作指令怎么執行呢？因為所有虛擬機的系統都被解除了特權，于是“陷入模擬”就發揮作用了，它解除了 Guest OS 的特權后，Guest OS 的大部分指令仍可以在硬體上直接運行，只有當執行到特權指令時，才會陷入到 VMM 模擬執行（陷入－模擬），由 VMM 代替虛擬機向真正的硬體 CPU 發出特權操作指 令，
CPU 虛擬化經典方法結合原始作業系統具有的定時器中斷機制，就完美解決了 CPU 虛擬化 的問題，如虛擬機 1 發送特權指令 1 到虛擬機監視器 VMM，此時觸發中斷，虛擬機監視器 VMM 會對虛擬機 1 發送的特權指令 1 陷入到虛擬機監視器 VMM 中進行模擬，再轉換成 CPU 的特權指令 1’，虛擬機監視器 VMM 根據調度機制調度到硬體 CPU 上執行，并回傳結果給 VM1，如下左圖，當虛擬機 1 和虛擬機 2 同時發送特權指令到虛擬機監視器 VMM 時，指令 都被陷入模擬，虛擬機監視器 VMM 調度機制進行統一調度，首先執行指令 1’，然后再執行指 令 2’如下右圖 ，于是采用定時器中斷機制以及特權解除—陷入模擬這些方法成功實作了 CPU 的虛擬化功能，
--------------------------------------------------------------------------------------
那為什么需要中斷機制呢？CPU 在程式運行中系統外部、系統內部或者現行程式本身若出 現緊急事件，CPU 立即中止現行程式的運行，自動轉入相應的處理程式（中斷服務程式），待處 理完后，再回傳原來的程式運行，這整個程序稱為程式中斷，例如你正在看視頻時，QQ 突然有 資訊彈出，在整個程序中就會觸發中斷機制，CPU 就會暫停視頻播放行程，而專區執行 QQ 進 程，CPU 在處理完成 QQ 行程操作后，繼續執行視頻播放行程，當然，這個中斷時間非常短 暫，用戶是無感知的，
隨著 x86 主機性能越來越強大，如何將虛擬化技術應用到 x86 架構成為實作 x86 服務器虛 擬化的主要問題，這個時候，人們自然而然想到曾經使用到大型機上的 CPU 虛擬化技術，那么 大型機 CPU 虛擬化所使用的經典虛擬化方法能否移植到 x86 服務器上呢？這個問題答案卻是否 定的，這又是為什么呢？要回答這個問題，我們就需要了解 x86 架構的 CPU 和大型機 CPU 的 不同之處，
大型機（包括后來發展的小型機）是 PowerPC 架構，即精簡指令集 RISC 計算機架構， RISC 架構的 CPU 指令集中，虛擬機特有的敏感指令是完全包括在特權指令中的，如下右圖所 示，在虛擬機作業系統解除特權后，特權指令和敏感指令都可被正常陷入-模擬并執行，因為特 權指令包含敏感指令，所以 RISC 架構的 CPU 采用特權解除和陷入模擬是沒有問題的，但是 x86 架構的 CPU 指令集是不同于 RISC 架構的 CISC 架構，如下圖所示，
| 
在上圖中可以看到 CISC 架構的 CPU 指令集的特權指令和敏感指令并不完全重合，具體來 說，基于 x86 的 CISC 指令集有 19 條敏感指令不屬于特權指令的范疇，這部分敏感指令運行在 CPU 的 Ring 1 用戶態上，這會帶來什么問題呢？顯然，當虛擬機發出這 19 條敏感指令時，由 于指令不屬于特權指令，因而這些敏感指令不能陷入-模擬被虛擬機監視器（VMM）捕獲，因此 x86 無法使用“解除特權”“陷入-模擬”經典的虛擬化技術方式實作 X86 架構的虛擬化，這樣的 問題被稱為虛擬化漏洞問題，既然基于大型機的 CPU 虛擬化方案無法直接移植到 x86 平臺上， 那么 x86 應該采用什么方式實作 CPU 虛擬化呢？
聰明的 IT 架構師想出了解決這個問題的方法，而且還是三種方法，它們分別是：全虛擬 化、半虛擬化以及硬體廠商提出的硬體輔助虛擬化，
CPU全虛擬化解決方案
經典虛擬化方案不適合 x86 架構的 CPU，其根本原因就在于那 19 條超出特權指令的敏感指 令，如何可以識別出這些敏感指令，并使其可以被 VMM 陷入——模擬，則 CPU 虛擬化就可以 被解決，但是如何識別出這 19 條指令呢？
有一種類似于“寧可錯殺三千，絕不放過一個”的思路，也就是說將所有虛擬機發出的操作 系統請求轉發到虛擬機監視器（VMM），虛擬機監視器對請求進行二進制翻譯（Binary Translation），如果發現是特權指令或敏感指令，則陷入到 VMM 模擬執行，然后調度到 CPU 特權級別上執行；如果只是應用程式指令則直接在 CPU 非特權級別上執行，這種方法由于需要 過濾所有虛擬機發出的請求指令，因而被稱為全虛擬化方式，全虛擬化的實作方式如下圖，
全虛擬化方案最早是由 Vmware 提出并實作，運行時虛擬機監視器 VMM 對虛擬機操作系 統 Guest OS 二進制代碼進行翻譯，不修改虛擬機作業系統，虛擬機的可移植性和兼容性較強，但二進制翻譯會帶來虛擬機監視器（VMM）性能的開銷，全虛擬化方式的優點是：不修改虛擬機作業系統，虛擬機的可移植性和兼容性較強，支持廣泛的作業系統；但缺點是運行時修改 Guest OS 二進制代碼，性能損耗較大，并且引入了新的復雜性，導致虛擬機監視器（VMM） 開發難度較大，正是因為全虛擬化具有上述的缺點，因此 Xen 提出半虛擬化解決方案，
| 
半虛擬化示意圖 全虛擬化示意圖
CPU半虛擬化解決方案
虛擬化漏洞的問題來源于 19 條敏感指令，如果我們可以修改虛擬機作業系統 Guest OS 規 避虛擬化漏洞，則問題就容易解決了，
修改虛擬機作業系統 Guest OS，讓虛擬機系統 Guest OS 能夠意識到自己是被虛擬化的， 虛擬機作業系統會通過“超級呼叫”（Hypercall）用 Hypervisor 層來替換虛擬化中的敏感指 令，從而實作虛擬化，而其它應用程式等非敏感或特權請求直接在 CPU 非特權級別上執行，半 虛擬化如上圖二所示，半虛擬化所具有的優點是：半虛擬化中的 Guest OS 可以同時能支持多個 不同的作業系統.，虛擬化提供了與原始系統相近的性能，但缺點是：半虛擬化中的 Host OS 只 有針對開源的系統才能支持被修改，如 Linux，而對于未開源的諸如 Windows 系統，則無法實 現半虛擬化，此外，被修改過的虛擬機作業系統 Guest OS 可移植性較差，
CPU硬體輔助虛擬化解決方案
虛擬化漏洞問題的解決，無論全虛擬還是半虛擬，都默認一個前提，即物理硬體是不具備虛擬化識別功能的，因此必須識別出這 19 條敏感指令，并通過虛擬化監視器 VMM 進行陷入——模擬，如果物理 CPU 直接支持虛擬化功能，并且可以識別敏感指令，那么 CPU 虛擬化方式就將發生革命性的變革，
幸運的是，目前主流的 x86 主機的 CPU 都支持硬體虛擬化技術，即 Intel 推出 VT-x 的 CPU，AMD 也推出了 AMD-V 的 CPU，Intel Virtualization Technology（VT-x）和 AMD 的 AMD-V，這兩種技術都為 CPU 增加了新的執行模式 root 模式，可以讓虛擬化監視器 VMM 運 行在 root 模式下，而 root 模式位于 CPU 指令級別 Ring 0 的下面，特權和敏感指令自動在 Hypervisor 上執行，從而無需全虛擬或半虛擬化技術，這種通過硬體輔助虛擬化解決虛擬化漏 洞，簡化 VMM 軟體，消除了半虛擬化和二進制翻譯的方法，被稱為 CPU 的硬體輔助虛擬化技術，但是需要在bios里把inter vt-x特性打開，不打開則不支持虛擬化特性，硬體輔助虛擬化技術如下圖所示，
硬體輔助虛擬化
記憶體虛擬化
CPU 實作了虛擬化之后，與 CPU 關系極為密切的硬體——記憶體也將發生巨大的變化，為什 么 CPU 虛擬化后會導致記憶體虛擬化的出現呢？
隨著 CPU 虛擬化的出現應用，運行在 VMM 層之上的虛擬機取代了物理主機，成為承載業 務和應用的載體，并且在一臺物理主機之上有多臺虛擬機同時運行著，那么問題就出來了，物理 主機通常只有一根或幾根記憶體條，面對多個虛擬機對記憶體的需求，該如何分配記憶體資源呢？顯然，解決問題的辦法還是虛擬化技術，因此記憶體虛擬化技術就出現了，記憶體虛擬化所遇到的一個問題就是，如何分配記憶體地址空間呢？因為通常情況下物理主機在使用記憶體地址空間時，都按照 如下兩點進行：
- 記憶體地址都是從物理地址 0 開始的
- 記憶體地址空間都是連續分配的 但引入虛擬化后顯然就出現了問題：首先是要求記憶體地址空間都從物理地址 0 開始，顯然物理地址為 0 的記憶體地址空間只有一個，無法同時滿足所有虛擬機記憶體使用都要從 0 開始的要求；
其次，地址連續分配問題，即使可以為虛擬機分配連續的物理地址，但是記憶體使用效率不高，缺 乏靈活性，
解決記憶體共享問題的思路就在于引入記憶體虛擬化技術，記憶體虛擬化就是把物理機的真實物理 記憶體統一管理，包裝成多份虛擬的記憶體給若干虛擬機使用，記憶體虛擬化技術的核心在于引入一層 新的地址空間——客戶機物理地址空間，客戶機（Guest）以為自己運行在真實的物理地址空間 中，實際上它是通過 VMM 訪問真實的物理地址的，在 VMM 中保存客戶機地址空間和物理機 地址空間之間的映射表，如下圖所示，
記憶體虛擬化的記憶體地址轉換涉及到三種記憶體地址，即虛擬機記憶體地址（Virtual Memory Address，即 VA）、物理記憶體地址（Physical Memory Address，即 PA）和機器記憶體地址（Machine Memory Address，即 MA），為了在物理主機上能夠運行多個虛擬機，需要實作VA（虛擬記憶體）→PA（物理記憶體）→MA（機器記憶體）直接的地址轉換，虛擬機 Guest OS 控 制虛擬地址到客戶記憶體物理地址的映射 （VA→PA），但是虛擬機 Guest OS 不能直接訪問實際 機器記憶體，因此 Hypervisor 需要負責映射客戶物理記憶體到實際機器記憶體（PA→MA），
注：這個地方可能有人要問 MA 和 PA 的區別，比如一臺服務器一共有 16 根 16G 的記憶體 條，那么它的 PA 為 256G，而 MA 為 16 根分布在不同記憶體槽位的記憶體條，
記憶體全虛擬化
通過使用影子頁表（Shadow Page Table）實作虛擬化，VMM為每個Guest都維護一個影子頁表，影子頁表維護虛擬地址（VA）到機器地址（MA）的映射關系，而Guest頁表維護VA到客戶機物理地址（GPA）的映射關系，當VMM捕獲到Guest頁表的修改后，VMM會查找負責GPA到MA映射的P2M頁表或者哈希函式，找到與該GPA對應的MA，再將MA填充到真正在硬體上起作用的影子頁表，從而形成VA到MA的映射關系，而Guest的頁表則無需變動，如下圖所示，
記憶體半虛擬化
通過使用頁表寫入法實作虛擬化，Guest OS在創建一個新的頁表時，會向VMM注冊該頁表，之后在Guest運行的時候，VMM將不斷地管理和維護這個表，使Guest上面的程式能直接訪問到合適的地址，
記憶體硬體輔助虛擬化
通過擴展頁表EPT（Extended Page Table）實作虛擬化，EPT通過使用硬體技術，使其能在原有的頁表的基礎上，增加一個EPT頁表，用于記錄GPA到MA的映射關系，VMM預先把EPT頁表設定到CPU中，Guest修改Guest頁表，無需VMM干預，地址轉換時，CPU自動查找兩張頁表完成Guest虛擬地址到機器地址的轉換，從而降低整個記憶體虛擬化所需的開銷，如下圖所示，
I/O 虛擬化
由于計算虛擬化的出現，物理服務器上會創建出許許多多的虛擬機，并且每臺虛擬機都需要 訪問物理主機的 IO 設備，但 I/O 設備的數量畢竟是有限的，為了滿足多個虛擬機共同使用 I/O 設備的需求，就需要虛擬化監視器 VMM 參與，VMM 用于截獲虛擬機對 I/O 設備的訪問請求， 再通過軟體去模擬真實的 I/O 設備，進而回應 I/O 請求，從而讓多個虛擬機訪問有限的 I/O 資 源，實作 I/O 虛擬化的方式主要有三種：全虛擬化、半虛擬化和硬體輔助虛擬化，其中硬體輔助虛擬化技術是目前 I/O 虛擬化的主流技術，
IO全虛擬化
全虛擬化的實作原理是，通過 VMM 為虛擬機模擬出一個與真實設備類似 的虛擬 I/O 設備，當虛擬機對 I/O 設備發起 I/O 請求時，VMM 截獲虛擬機下發的 I/O 訪問請 求，再由 VMM 將真實的訪問請求發送到物理設備進行處理，這種虛擬化方式的優點在于：虛擬 機無論使用任何型別的作業系統，作業系統都不需要為 I/O 虛擬化做任何修改，就可以讓多個虛 擬機直接使用物理服務器的 I/O 設備，但這種方式的缺陷也在于，VMM 需要實時截獲每個虛擬 機下發的 I/O 請求，截獲請求后模擬到真實的 I/O 設備中，實時監控和模擬的操作都是通過CPU 運行軟體程式來實作的，因此會對服務器帶來較嚴重的性能損耗，
IO半虛擬化
半虛擬化方式與全虛擬化方式的明顯區別在于，它需要建立一個特權級別的 虛擬機，即特權虛擬機，半虛擬化方式要求各個虛擬機運行前端驅動程式，當需要訪問 I/O 設備 時，虛擬機通過前端驅動程式把 I/O 請求發送給特權虛擬機，由特權虛擬機的后端驅動收集每個 虛擬機所發出的 I/O 請求，再由后端驅動對多個 I/O 請求進行分時分通道處理，特權虛擬機運行真實的物理 I/O 設備驅動，將 I/O 請求發送給物理 I/O 設備，I/O 設備處理完成后再將結果回傳給虛擬機，半虛擬化方式的優點在于，主動讓虛擬機把 I/O 請求發送給特權虛擬機，再由特權虛 擬機訪問真實的 I/O 設備，這就減少了 VMM 的性能損耗，但這種方式也有一個缺陷，即需要修 改虛擬機作業系統，改變作業系統對自身 I/O 請求的處理方式，將 I/O 請求全部發給特權虛擬機 處理，這就要求虛擬機作業系統是屬于可以被修改的型別（通常都是 Linux 型別），XEN就是典型的IO半虛擬化，如下圖 所示，
Xen 架構示意圖
在上圖中，Domain 0 就是特權虛擬機，Domain U 則為用戶虛擬機，所有用戶虛擬機 的設備資訊保存在特權虛擬機 Domain0 的 XenSToRe 中，用戶虛擬機中的 XenBus (為 Xen 開 發的半虛擬化驅動)通過與 Domain0 的 XenSToRe 通信，獲取設備資訊，加載設備對應的前端 驅動程式，當用戶虛擬機有 I/O 請求時，前端設備驅動將資料通過介面全部轉發到后端驅動，后 端驅動則對 I/O 請求的資料進行分時分通道進行處理，最終通過 Domain 0 的物理 I/O 設備驅 動，將 I/O 請求發送給物理 I/O 設備，
我們可以舉例比較全虛擬化和半虛擬化兩種方式，全虛擬化就相當于 VMM 扮演著一個調查員的角色，它需要自己去收集和歸納每一位客戶的意見要求；而半虛擬化則相當于準備好了一個 意見收納箱（即特權虛擬機），然后各個用戶自行將意見要求放入收納箱，VMM 再統一處理這 些意見請求，由于半虛擬化顯著減少了 VMM 的性能損耗，因而能獲得更好的 I/O 性能，但我們也注意到，全虛擬化和半虛擬化這兩種方式都有一個共同的特點，即 I/O 訪問處理都需要由VMM 介入，這勢必造成虛擬機在訪問 I/O 設備時的性能損耗，
前面我們說過，QEMU 是一個軟體實作 IO 虛擬化的模擬工具，性能較差，例如，如果使用 QEMU 模擬一個 Windows 虛擬機的網卡，我們在系統上看到的該網卡的速率僅為 100M，有 時候一些應用對網卡速率有要求時，就不能再使用 QEMU 了，我們需要引入一個新的技術，它 就是 Virtio，是用了 Virtio，同樣是網卡，在 Windows 虛擬化上，該網卡的速率可以提升到 10G，
我們先了解一下，如果沒有 Virtio 時，虛擬機磁盤操作如何實作：
默認 I/O 操作流程
1 、虛擬機中的磁盤設備發起一次 IO 操作請求；
2 、KVM 模塊中的 I/O Trap Code（I/O 捕獲程式）將這個 IO 操作請求捕獲到，進行 相應的處理，然后將處理后的請求放到 I/O 共享頁中；
3 、KVM 模塊會通知 QEMU，告訴它有新的 I/O 操作請求放到了共享頁中；
4 、QEMU 收到通知后，到共享頁中獲取該 I/O 操作請求的具體資訊；
5 、QEMU 對該請求進行模擬，同時根據 I/O 操作請求的資訊呼叫運行在內核態的設備驅動，去進行真正的 IO 操作；
6 、通過設備驅動去對物理硬體執行真正的 IO 操作；
7 、QEMU 將執行后的結果回傳到共享頁中，同時通知 KVM 模塊已完成了此次的 I/O 操作；
8 、I/O 捕獲程式從共享頁中將回傳的結果讀取出來；
9 、I/O 捕獲程式將操作結果回傳給虛擬機；
10、虛擬機的將結果回傳給發起操作的應用程式，
注：注意第 2、3、7 步，其實 KVM 除了捕獲和通知，并沒有對 I/O 操作做任何的修改，既 然什么都內有修改，那么我們都能不能把這一步去掉呢，所以就開發出了新的 virtio 技術，如果使用 Virtio 的時候，具體的操作流程如下：
Virtio 下 I/O 操作流程
1 、第一步也是由虛擬機發起 I/O 操作請求；
2 、第二步的時候和使用默認模型不一樣，這個 I/O 操作請求不會經過 I/O 捕獲程式， 而是直接以前后端的形式放到環形緩沖區，同時 KVM 模塊通知后端驅動；
3 、QEMU 到環形緩沖區獲取到操作請求的具體資訊；
4 、后端驅動直接呼叫真實的物理設備驅動進行具體的 I/O 操作；
5 、由真實的設備驅動完成此次操作；
6 、QEMU 將完成結果回傳到環形緩沖區，并且由 KVM 模塊通知前端驅動；
7 、前端驅動從環形緩沖區獲取到此次 I/O 操作的結果；
8 、前端驅動將結果回傳給具體發起該操作的應用程式， 通過對以上具體流程的介紹，我們可以得出使用 Virtio 的優點：
- 節省 QEMU 模擬時所需的硬體資源；
- 減少 I/O 請求的路徑，提高了虛擬化設備的性能，
Virtio 也存在著一些缺點，有些比較老的或者不常用的設備，無法使用，只能使用 QEMU 方式進行模擬，
所以我們現在的虛擬化一般都叫QEMU-KVM，即QEMU實作IO虛擬化，KVM實作CPU和記憶體的虛擬化，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/253437.html
標籤：其他