虛擬化技術簡介

什麼是虛擬化

虛擬化（Virtualization）技術最早出現在 20 世紀 60 年代的 IBM 大型機系統，在70年代的 System 370 系列中逐漸流行起來，這些機器通過一種叫虛擬機器監控器（Virtual Machine Monitor，VMM）的程式在物理硬體之上生成許多可以執行獨立作業系統軟體的虛擬機器（Virtual Machine）例項。隨著近年多核系統、叢集、網格甚至雲端計算的廣泛部署，虛擬化技術在商業應用上的優勢日益體現，不僅降低了 IT 成本，而且還增強了系統安全性和可靠性，虛擬化的概念也逐漸深入到人們日常的工作與生活中。

虛擬化是一個廣義的術語，對於不同的人來說可能意味著不同的東西，這要取決他們所處的環境。在電腦科學領域中，虛擬化代表著對計算資源的抽象，而不僅僅侷限於虛擬機器的概念。例如對實體記憶體的抽象，產生了虛擬記憶體技術，使得應用程式認為其自身擁有連續可用的地址空間（Address Space），而實際上，應用程式的程式碼和資料可能是被分隔成多個碎片頁或段），甚至被交換到磁碟、快閃記憶體等外部儲存器上，即使實體記憶體不足，應用程式也能順利執行。

虛擬化技術的分類

虛擬化技術主要分為以下幾個大類 [1]：

1. 平臺虛擬化（Platform Virtualization），針對計算機和作業系統的虛擬化。
2. 資源虛擬化（Resource Virtualization），針對特定的系統資源的虛擬化，比如記憶體、儲存、網路資源等。
3. 應用程式虛擬化（Application Virtualization），包括模擬、模擬、解釋技術等。

我們通常所說的虛擬化主要是指平臺虛擬化技術，通過使用控制程式（Control Program，也被稱為 Virtual Machine Monitor 或 Hypervisor），隱藏特定計算平臺的實際物理特性，為使用者提供抽象的、統一的、模擬的計算環境（稱為虛擬機器）。虛擬機器中執行的作業系統被稱為客戶機作業系統（Guest OS），執行虛擬機器監控器的作業系統被稱為主機作業系統（Host OS），當然某些虛擬機器監控器可以脫離作業系統直接執行在硬體之上（如 VMWARE 的 ESX 產品）。執行虛擬機器的真實系統我們稱之為主機系統。

平臺虛擬化技術又可以細分為如下幾個子類：

1. 全虛擬化（Full Virtualization）
   全虛擬化是指虛擬機器模擬了完整的底層硬體，包括處理器、實體記憶體、時鐘、外設等，使得為原始硬體設計的作業系統或其它系統軟體完全不做任何修改就可以在虛擬機器中執行。作業系統與真實硬體之間的互動可以看成是通過一個預先規定的硬體介面進行的。全虛擬化 VMM 以完整模擬硬體的方式提供全部介面（同時還必須模擬特權指令的執行過程）。舉例而言，x86 體系結構中，對於作業系統切換程序頁表的操作，真實硬體通過提供一個特權 CR3 暫存器來實現該介面，作業系統只需執行 “mov pgtable,%%cr3” 彙編指令即可。全虛擬化 VMM 必須完整地模擬該介面執行的全過程。如果硬體不提供虛擬化的特殊支援，那麼這個模擬過程將會十分複雜：一般而言，VMM 必須執行在最高優先順序來完全控制主機系統，而 Guest OS 需要降級執行，從而不能執行特權操作。當 Guest OS 執行前面的特權彙編指令時，主機系統產生異常（General Protection Exception），執行控制權重新從 Guest OS 轉到 VMM 手中。VMM 事先分配一個變數作為影子 CR3 暫存器給 Guest OS，將 pgtable 代表的客戶機實體地址（Guest Physical Address）填入影子 CR3 暫存器，然後 VMM 還需要 pgtable 翻譯成主機實體地址（Host Physical Address）並填入物理 CR3 暫存器，最後返回到 Guest OS中。隨後 VMM 還將處理複雜的 Guest OS 缺頁異常（Page Fault）。比較著名的全虛擬化 VMM 有 Microsoft Virtual PC、VMware Workstation、Sun Virtual Box、Parallels Desktop for Mac 和 QEMU。

2. 超虛擬化（Paravirtualization）
   這是一種修改 Guest OS 部分訪問特權狀態的程式碼以便直接與 VMM 互動的技術。在超虛擬化虛擬機器中，部分硬體介面以軟體的形式提供給客戶機作業系統，這可以通過 Hypercall（VMM 提供給 Guest OS 的直接呼叫，與系統呼叫類似）的方式來提供。例如，Guest OS 把切換頁表的程式碼修改為呼叫 Hypercall 來直接完成修改影子 CR3 暫存器和翻譯地址的工作。由於不需要產生額外的異常和模擬部分硬體執行流程，超虛擬化可以大幅度提高效能，比較著名的 VMM 有 Denali、Xen。

3. 硬體輔助虛擬化（Hardware-Assisted Virtualization）
   硬體輔助虛擬化是指藉助硬體（主要是主機處理器）的支援來實現高效的全虛擬化。例如有了 Intel-VT 技術的支援，Guest OS 和 VMM 的執行環境自動地完全隔離開來，Guest OS 有自己的“全套暫存器”，可以直接執行在最高級別。因此在上面的例子中，Guest OS 能夠執行修改頁表的彙編指令。Intel-VT 和 AMD-V 是目前 x86 體系結構上可用的兩種硬體輔助虛擬化技術。

4. 部分虛擬化（Partial Virtualization）
   VMM 只模擬部分底層硬體，因此客戶機作業系統不做修改是無法在虛擬機器中執行的，其它程式可能也需要進行修改。在歷史上，部分虛擬化是通往全虛擬化道路上的重要里程碑，最早出現在第一代的分時系統 CTSS 和 IBM M44/44X 實驗性的分頁系統中。

5. 作業系統級虛擬化（Operating System Level Virtualization）
   在傳統作業系統中，所有使用者的程序本質上是在同一個作業系統的例項中執行，因此核心或應用程式的缺陷可能影響到其它程序。作業系統級虛擬化是一種在伺服器作業系統中使用的輕量級的虛擬化技術，核心通過建立多個虛擬的作業系統例項（核心和庫）來隔離不同的程序，不同例項中的程序完全不瞭解對方的存在。比較著名的有 Solaris Container [2]，FreeBSD Jail 和 OpenVZ 等。

這種分類並不是絕對的，一個優秀的虛擬化軟體往往融合了多項技術。例如 VMware Workstation 是一個著名的全虛擬化的 VMM，但是它使用了一種被稱為動態二進位制翻譯的技術把對特權狀態的訪問轉換成對影子狀態的操作，從而避免了低效的 Trap-And-Emulate 的處理方式，這與超虛擬化相似，只不過超虛擬化是靜態地修改程式程式碼。對於超虛擬化而言，如果能利用硬體特性，那麼虛擬機器的管理將會大大簡化，同時還能保持較高的效能。

本文討論的虛擬化技術只針對 x86 平臺（含 AMD 64），並假定虛擬機器中執行的 Guest OS 也是為 x86 平臺設計的。

純軟體虛擬化技術的原理及面臨的挑戰

虛擬機器監控器應當具備的條件

1974 年，Popek 和 Goldberg 在《Formal Requirements for Virtualizable Third Generation Architectures》[3] 論文中提出了一組稱為虛擬化準則的充分條件，滿足這些條件的控制程式可以被稱為虛擬機器監控器（Virtual Machine Monitor，簡稱 VMM）：

資源控制。控制程式必須能夠管理所有的系統資源。
等價性。在控制程式管理下執行的程式（包括作業系統），除時序和資源可用性之外的行為應該與沒有控制程式時的完全一致，且預先編寫的特權指令可以自由地執行。
效率性。絕大多數的客戶機指令應該由主機硬體直接執行而無需控制程式的參與。
儘管基於簡化的假設，但上述條件仍為評判一個計算機體系結構是否能夠有效支援虛擬化提供了一個便利方法，也為設計可虛擬化計算機架構給出了指導原則。

原理簡介

我們知道，傳統的 x86 體系結構缺乏必要的硬體支援，任何虛擬機器監控器都無法直接滿足上述條件，所以不是一個可虛擬化架構，但是我們可以使用純軟體實現的方式構造虛擬機器監控器。

虛擬機器是對真實計算環境的抽象和模擬，VMM 需要為每個虛擬機器分配一套資料結構來管理它們狀態，包括虛擬處理器的全套暫存器，實體記憶體的使用情況，虛擬裝置的狀態等等。VMM 排程虛擬機器時，將其部分狀態恢復到主機系統中。並非所有的狀態都需要恢復，例如主機 CR3 暫存器中存放的是 VMM 設定的頁表實體地址，而不是 Guest OS 設定的值。主機處理器直接執行 Guest OS 的機器指令，由於 Guest OS執行在低特權級別，當訪問主機系統的特權狀態（如寫 GDT 暫存器）時，許可權不足導致主機處理器產生異常，將執行權自動交還給 VMM。此外，外部中斷的到來也會導致 VMM 的執行。VMM 可能需要先將 該虛擬機器的當前狀態寫回到狀態資料結構中，分析虛擬機器被掛起的原因，然後代表 Guest OS 執行相應的特權操作。最簡單的情況，如Guest OS 對 CR3 暫存器的修改，只需要更新虛擬機器的狀態資料結構即可。一般而言，大部分情況下，VMM 需要經過複雜的流程才能完成原本簡單的操作。最後 VMM 將執行權還給 Guest OS，Guest OS 從上次被中斷的地方繼續執行，或處理 VMM “塞”入的虛擬中斷和異常。這種經典的虛擬機器執行方式被稱為 Trap-And-Emulate，虛擬機器對於 Guest OS 完全透明，Guest OS 不需要任何修改，但是 VMM 的設計會比較複雜，系統整體效能受到明顯的損害。

面臨的挑戰

在設計純軟體 VMM 的時候，需要解決如下挑戰 [4]：

確保 VMM 控制所有的系統資源。
x86 處理器有 4 個特權級別，Ring 0 ~ Ring 3，只有執行在 Ring 0 ~ 2 級時，處理器才可以訪問特權資源或執行特權指令；執行在 Ring 0 級時，處理器可以訪問所有的特權狀態。x86 平臺上的作業系統一般只使用 Ring 0 和 Ring 3 這兩個級別，作業系統執行在 Ring 0 級，使用者程序執行在 Ring 3 級。為了滿足上面的第一個充分條件-資源控制，VMM 自己必須執行在 Ring 0 級，同時為了避免 Guest OS 控制系統資源，Guest OS 不得不降低自身的執行級別，執行在 Ring 1 或 Ring 3 級（Ring 2 不使用）。

特權級壓縮（Ring Compression）。
VMM 使用分頁或段限制的方式保護實體記憶體的訪問，但是 64 位模式下段限制不起作用，而分頁又不區分 Ring 0, 1, 2。為了統一和簡化 VMM的設計，Guest OS 只能和 Guest 程序一樣執行在 Ring 3 級。VMM 必須監視 Guest OS 對 GDT、IDT 等特權資源的設定，防止 Guest OS 執行在 Ring 0級，同時又要保護降級後的 Guest OS 不受 Guest 程序的主動攻擊或無意破壞。

特權級別名（Ring Alias）。
特權級別名是指 Guest OS 在虛擬機器中執行的級別並不是它所期望的。VMM 必須保證 Guest OS 不能獲知正在虛擬機器中執行這一事實，否則可能打破等價性條件。例如，x86 處理器的特權級別存放在 CS 程式碼段暫存器內，Guest OS 可以使用非特權 push 指令將 CS 暫存器壓棧，然後 pop 出來檢查該值。又如，Guest OS 在低特權級別時讀取特權暫存器 GDT、LDT、IDT 和 TR，並不發生異常，從而可能發現這些值與自己期望的不一樣。為了解決這個挑戰，VMM 可以使用動態二進位制翻譯的技術，例如預先把 “push %%cs” 指令替換，在棧上存放一個影子 CS 暫存器值；又如，可以把讀取 GDT 暫存器的操作“sgdt dest”改為“movl fake_gdt, dest”。

地址空間壓縮（Address Space Compression）。
地址空間壓縮是指 VMM 必須在Guest OS 的地址空間中保留一部分供其使用。例如，中斷描述表暫存器（IDT Register）中存放的是中斷描述表的線性地址，如果 Guest OS 執行過程中來了外部中斷或觸發處理器異常，必須保證執行權馬上轉移到 VMM 中，因此 VMM 需要將 Guest OS 的一部分線性地址空間對映成自己的中斷描述表的主機實體地址。VMM 可以完全執行在 Guest OS 的地址空間中，也可以擁有獨立的地址空間，後者的話，VMM 只佔用 Guest OS 很少的地址空間，用於存放中斷描述表和全域性描述符表（GDT）等重要的特權狀態。無論如何哪種情況，VMM 應該防止 Guest OS 直接讀取和修改這部分地址空間。

處理 Guest OS 的缺頁異常。
記憶體是一種非常重要的系統資源，VMM 必須全權管理，Guest OS 理解的實體地址只是客戶機實體地址（Guest Physical Address），並不是最終的主機實體地址（Host Physical Address）。當 Guest OS 發生缺頁異常時，VMM 需要知道缺頁異常的原因，是 Guest 程序試圖訪問沒有許可權的地址，或是客戶機線性地址（Guest Linear Address）尚未翻譯成 Guest Physical Address，還是客戶機實體地址尚未翻譯成主機實體地址。一種可行的解決方法是 VMM 為 Guest OS 的每個程序的頁表構造一個影子頁表，維護 Guest Linear Address 到 Host Physical Address 的對映，主機 CR3 暫存器存放這個影子頁表的實體記憶體地址。VMM 同時維護一個 Guest OS 全域性的 Guest Physical Address 到 Host Physical Address 的對映表。發生缺頁異常的地址總是Guest Linear Address，VMM 先去 Guest OS 中的頁表檢查原因，如果頁表項已經建立，即對應的Guest Physical Address 存在，說明尚未建立到 Host Physical Address的對映，那麼 VMM 分配一頁實體記憶體，將影子頁表和對映表更新；否則，VMM 返回到 Guest OS，由 Guest OS 自己處理該異常。

處理 Guest OS 中的系統呼叫。
系統呼叫是作業系統提供給使用者的服務例程，使用非常頻繁。最新的作業系統一般使用 SYSENTER/SYSEXIT 指令對來實現快速系統呼叫。SYSENTER 指令通過IA32_SYSENTER_CS，IA32_SYSENTER_EIP 和 IA32_SYSENTER_ESP 這 3 個 MSR（Model Specific Register）暫存器直接轉到 Ring 0級；而 SYSEXIT 指令不在 Ring 0 級執行的話將觸發異常。因此，如果 VMM 只能採取 Trap-And-Emulate 的方式處理這 2 條指令的話，整體效能將會受到極大損害。

轉發虛擬的中斷和異常。
所有的外部中斷和主機處理器的異常直接由 VMM 接管，VMM 構造必需的虛擬中斷和異常，然後轉發給 Guest OS。VMM 需要模擬硬體和作業系統對中斷和異常的完整處理流程，例如 VMM 先要在 Guest OS 當前的核心棧上壓入一些資訊，然後找到 Guest OS 相應處理例程的地址，並跳轉過去。VMM 必須對不同的 Guest OS 的內部工作流程比較清楚，這增加了 VMM 的實現難度。同時，Guest OS 可能頻繁地遮蔽中斷和啟用中斷，這兩個操作訪問特權暫存器 EFLAGS，必須由 VMM 模擬完成，效能因此會受到損害。 Guest OS 重新啟用中斷時，VMM 需要及時地獲知這一情況，並將積累的虛擬中斷轉發。

Guest OS 頻繁訪問特權資源。
Guest OS對特權資源的每次訪問都會觸發處理器異常，然後由 VMM 模擬執行，如果訪問過於頻繁，則系統整體效能將會受到極大損害。比如對中斷的遮蔽和啟用，cli（Clear Interrupts）指令在 Pentium 4 處理器上需要花費 60 個時鐘週期（cycle）。又如，處理器本地高階可程式設計中斷處理器（Local APIC）上有一個作業系統可修改的任務優先順序暫存器（Task-Priority Register），IO-APIC 將外部中斷轉發到 TPR 值最低的處理器上（期望該處理器正在執行低優先順序的執行緒），從而優化中斷的處理。TPR 是一個特權暫存器，某些作業系統會頻繁設定（Linux Kernel只在初始化階段為每個處理器的 TPR 設定相同的值）。

軟體 VMM 所遇到的以上挑戰從本質上來說是因為 Guest OS 無法執行在它所期望的最高特權級，傳統的 Trap-And-Emulate 處理方式雖然以透明的方式基本解決上述挑戰，但是帶來極大的設計複雜性和效能下降。當前比較先進的虛擬化軟體結合使用二進位制翻譯和超虛擬化的技術，核心思想是動態或靜態地改變 Guest OS 對特權狀態訪問的操作，儘量減少產生不必要的硬體異常，同時簡化 VMM 的設計。

Intel-VT 硬體輔助虛擬化技術詳解

2005 年冬天，英特爾帶來了業內首個面向桌上型電腦的硬體輔助虛擬化技術 Intel-VT 及相關的處理器產品，從而拉開了 IA 架構虛擬化技術應用的新時代大幕。支援虛擬化技術的處理器帶有特別優化過的指令集來自動控制虛擬化過程，從而極大簡化 VMM 的設計，VMM 的效能也能得到很大提高。其中 IA-32 處理器的虛擬化技術稱為 VT-x，安騰處理器的虛擬化技術稱為 VT-i。AMD 公司也推出了自己的虛擬化解決方案，稱為 AMD-V。儘管 Intel-VT 和 AMD-V 並不完全相同，但是基本思想和資料結構卻是相似的，本文只討論 Intel-VT-x 技術。

新增的兩種操作模式

VT-x 為 IA 32 處理器增加了兩種操作模式：VMX root operation 和 VMX non-root operation。VMM 自己執行在 VMX root operation 模式，VMX non-root operation 模式則由 Guest OS 使用。兩種操作模式都支援 Ring 0 ~ Ring 3 這 4 個特權級，因此 VMM 和 Guest OS 都可以自由選擇它們所期望的執行級別。

這兩種操作模式可以互相轉換。執行在 VMX root operation 模式下的 VMM 通過顯式呼叫 VMLAUNCH 或 VMRESUME 指令切換到 VMX non-root operation 模式，硬體自動載入 Guest OS的上下文，於是 Guest OS 獲得執行，這種轉換稱為 VM entry。Guest OS 執行過程中遇到需要 VMM 處理的事件，例如外部中斷或缺頁異常，或者主動呼叫 VMCALL 指令呼叫 VMM 的服務的時候（與系統呼叫類似），硬體自動掛起 Guest OS，切換到 VMX root operation 模式，恢復 VMM 的執行，這種轉換稱為 VM exit。VMX root operation 模式下軟體的行為與在沒有 VT-x 技術的處理器上的行為基本一致；而VMX non-root operation 模式則有很大不同，最主要的區別是此時執行某些指令或遇到某些事件時，發生 VM exit。

虛擬機器控制塊

VMM 和 Guest OS 共享底層的處理器資源，因此硬體需要一個實體記憶體區域來自動儲存或恢復彼此執行的上下文。這個區域稱為虛擬機器控制塊（VMCS），包括客戶機狀態區（Guest State Area），主機狀態區（Host State Area）和執行控制區。VM entry 時，硬體自動從客戶機狀態區載入 Guest OS 的上下文。並不需要儲存 VMM 的上下文，原因與中斷處理程式類似，因為 VMM 如果開始執行，就不會受到 Guest OS的干擾，只有 VMM 將工作徹底處理完畢才可能自行切換到 Guest OS。而 VMM 的下次執行必然是處理一個新的事件，因此每次 VMM entry 時， VMM 都從一個通用事件處理函式開始執行；VM exit 時，硬體自動將 Guest OS 的上下文儲存在客戶機狀態區，從主機狀態區中載入 VMM 的通用事件處理函式的地址，VMM 開始執行。而執行控制區存放的則是可以操控 VM entry 和 exit 的標誌位，例如標記哪些事件可以導致 VM exit，VM entry 時準備自動給 Guest OS “塞”入哪種中斷等等。

客戶機狀態區和主機狀態區都應該包含部分物理暫存器的資訊，例如控制暫存器 CR0，CR3，CR4；ESP 和 EIP（如果處理器支援 64 位擴充套件，則為 RSP，RIP）；CS，SS，DS，ES，FS，GS 等段暫存器及其描述項；TR，GDTR，IDTR 暫存器；IA32_SYSENTER_CS，IA32_SYSENTER_ESP，IA32_SYSENTER_EIP 和 IA32_PERF_GLOBAL_CTRL 等 MSR 暫存器。客戶機狀態區並不包括通用暫存器的內容，VMM 自行決定是否在 VM exit 的時候儲存它們，從而提高了系統性能。客戶機狀態區還包括非物理暫存器的內容，比如一個 32 位的 Active State 值表明 Guest OS 執行時處理器所處的活躍狀態，如果正常執行指令就是處於 Active 狀態，如果觸發了三重故障（Triple Fault）或其它嚴重錯誤就處於 Shutdown 狀態，等等。

前文已經提過，執行控制區用於存放可以操控 VM entry 和 VM exit 的標誌位，包括：

External-interrupt exiting：用於設定是否外部中斷可以觸發 VM exit，而不論 Guest OS 是否遮蔽了中斷。
Interrupt-window exiting：如果設定，當 Guest OS 解除中斷遮蔽時，觸發 VM exit。
Use TPR shadow：通過 CR8 訪問 Task Priority Register（TPR）的時候，使用 VMCS 中的影子 TPR，可以避免觸發 VM exit。同時執行控制區還有一個 TPR 閾值的設定，只有當 Guest OS 設定的 TR 值小於該閾值時，才觸發 VM exit。
CR masks and shadows：每個控制暫存器的每一位都有對應的掩碼，控制 Guest OS 是否可以直接寫相應的位，或是觸發 VM exit。同時 VMCS 中包括影子控制暫存器，Guest OS 讀取控制暫存器時，硬體將影子控制暫存器的值返回給 Guest OS。
VMCS 還包括一組點陣圖以提供更好的適應性：

Exception bitmap：選擇哪些異常可以觸發 VM exit，
I/O bitmap：對哪些 16 位的 I/O 埠的訪問觸發 VM exit。
MSR bitmaps：與控制暫存器掩碼相似，每個 MSR 暫存器都有一組“讀”的點陣圖掩碼和一組“寫”的點陣圖掩碼。
每次發生 VM exit時，硬體自動在 VMCS 中存入豐富的資訊，方便 VMM 甄別事件的種類和原因。VM entry 時，VMM 可以方便地為 Guest OS 注入事件（中斷和異常），因為 VMCS 中存有 Guest OS 的中斷描述表（IDT）的地址，因此硬體能夠自動地呼叫 Guest OS 的處理程式。

更詳細的資訊請參閱 Intel 開發手冊 [5]。

解決純軟體虛擬化技術面臨的挑戰

首先，由於新的操作模式的引入，VMM 和 Guest OS 的執行由硬體自動隔離開來，任何關鍵的事件都可以將系統控制權自動轉移到 VMM，因此 VMM 能夠完全控制系統的全部資源。

其次，Guest OS 可以執行在它所期望的最高特權級別，因此特權級壓縮和特權級別名的問題迎刃而解，而且 Guest OS 中的系統呼叫也不會觸發 VM exit。

硬體使用實體地址訪問虛擬機器控制塊（VMCS），而 VMCS 儲存了 VMM 和 Guest OS 各自的 IDTR 和 CR3 暫存器，因此 VMM 可以擁有獨立的地址空間，Guest OS 能夠完全控制自己的地址空間，地址空間壓縮的問題也不存在了。

中斷和異常虛擬化的問題也得到了很好的解決。VMM 只用簡單地設定需要轉發的虛擬中斷或異常，在 VM entry 時，硬體自動呼叫 Guest OS 的中斷和異常處理程式，大大簡化 VMM 的設計。同時，Guest OS 對中斷的遮蔽及解除可以不觸發 VM exit，從而提高了效能。而且 VMM 還可以設定當 Guest OS 解除中斷遮蔽時觸發 VM exit，因此能夠及時地轉發積累的虛擬中斷和異常。

未來虛擬化技術的發展

我們可以看到，硬體輔助虛擬化技術必然是未來的方向。Intel-VT目前還處在處理器級虛擬化技術的初級階段，尚需在如下方面進行發展：

1. 提高操作模式間的轉換速度。
   兩種操作模式間的轉換髮生之如此頻繁，如果不能有效減少其轉換速度，即使充分利用硬體特性，虛擬機器的整體效能也會大打折扣。早期的支援硬體輔助虛擬化技術的 Pentium 4 處理器需要花費 2409 個時鐘週期處理 VM entry，花費 508 個時鐘週期處理由缺頁異常觸發的 VM exit，代價相當高。隨著 Intel 技術的不斷完善，在新的 Core 架構上，相應時間已經減少到 937 和 446 個時鐘週期。未來硬體廠商還需要進一步提高模式的轉換速度，並提供更多的硬體特性來減少不必要的轉換。

2. 優化翻譯後援緩衝器（TLB）的效能。
   每次 VM entry 和 VM exit 發生時，由於需要重新載入 CR3 暫存器，因此 TLB（Translation Lookaside Buffer）被完全清空。虛擬化系統中操作模式的轉換髮生頻率相當高，因此係統的整體效能受到明顯損害。一種可行的方案是為 VMM 和每個虛擬機器分配一個全域性唯一 ID，TLB 的每一項附加該 ID 資訊來索引線性地址的翻譯。

3. 提供記憶體管理單元（MMU）虛擬化的硬體支援。
   即使使用 Intel-VT 技術，VMM 還是得用老辦法來處理 Guest OS 中發生的缺頁異常以及Guest OS 的客戶機實體地址到主機實體地址的翻譯，本質原因是 VMM 完全控制主機實體記憶體，因此 Guest OS 中的線性地址的翻譯同時牽涉到 VMM 和 Guest OS 的地址空間，而硬體只能看到其中的一個。Intel 和 AMD 提出了各自的解決方案，分別叫做 EPT（Extended Page Table）和 Nested Paging。這兩種技術的基本思想是，無論何時遇到客戶機實體地址，硬體自動搜尋 VMM 提供的關於該 Guest OS 的一個頁表，翻譯成主機實體地址，或產生缺頁異常來觸發 VM exit。

4. 支援高效的 I/O 虛擬化。
   I/O 虛擬化需要考慮效能、可用性、可擴充套件性、可靠性和成本等多種因素。最簡單的方式是 VMM為虛擬機器模擬一個常見的 I/O 裝置，該裝置的功能由 VMM 用軟體或複用主機 I/O 裝置的方法實現。例如 Virtual PC 虛擬機器提供的是一種比較古老的 S3 Trio64顯示卡。這種方式提高了相容性，並充分利用 Guest OS 自帶的裝置驅動程式，但是虛擬的 I/O 裝置功能有限且效能低下。為了提高效能，VMM 可以直接將主機 I/O 裝置分配給虛擬機器，這會帶來兩個主要挑戰：1. 如果多個虛擬機器可以複用同一個裝置，VMM 必須保證它們對裝置的訪問不會互相干擾。2. 如果 Guest OS 使用 DMA 的方式訪問 I/O 裝置，由於 Guest OS 給出的地址並不是主機實體地址，VMM 必須保證在啟動 DMA 操作前將該地址正確轉換。Intel 和 AMD 分別提出了各自的解決方案，分別稱為 Direct I/O（VT-d）和 IOMMU，希望用硬體的手段解決這些問題，降低 VMM 實現的難度。

結束語

本文針對 x86 平臺，介紹虛擬化技術的基本知識，希望對讀者的工作和學習有所裨益，更多詳細資訊請參閱參考資料一節。

原文連結： https://www.ibm.com/developerworks/cn/linux/l-cn-vt/?mhq=虛擬化&mhsrc=ibmsearch_a