x86硬件輔助虛擬化之虛擬機與VMM
理清虛擬機和虛擬機監視器的類別
大家在談到虛擬機時可能會有不同的看法：編程的朋友肯定對JVM不會陌生，JVM本身就是一種虛擬機；而喜歡系統虛擬軟件的朋友則對VMware、Xen和微軟這些虛擬化廠家的虛擬化產品有著更實際的理解。大家只知道它們是不同類別的虛擬機，但是它們之間是如何分類的呢？哪種虛擬機與Intel VT和AMD-V的關聯性***呢？
兩類不同的虛擬機
根據筆者的理解，虛擬機可以分為進程虛擬機和系統虛擬機兩大類，進程虛擬機支持ABI——用戶指令加上系統調用；系統虛擬機則支持完整的ISA——包括用戶指令和系統指令。在這個分類方法中，又可以根據客戶機和本地機(Host Machine，在虛擬化資料中也常常稱其為宿主機)是否使用了相同的ISA進行次級細分。
虛擬機大致可分為兩大類，并可進一步細分
為了簡化講解，我們只考慮和硬件虛擬化關系最為密切的、在相同ISA情況下的系統虛擬機(右圖中黑框圈選的地方，因為大部分讀者接觸不到不同ISA指令集轉換的情況)分類情況。前面我們提到的VMware、Xen的虛擬軟件產品都屬于系統虛擬機類別，而Intel VT和AMD-V等x86硬件輔助虛擬化技術能夠提升系統虛擬機的執行性能。
#p#
三種虛擬機監視器(VMM)
大家談到虛擬化時最常用的一個詞就是VMM(也稱作Hypervisor，虛擬機監控器，基本上大家可以認為就是前文講到的那個虛擬化層，抽象層的替代品)，在系統虛擬機中虛擬軟件常常被稱為VMM，VMM在虛擬機中可以算是最為關鍵的組件，對于系統虛擬機的分類就是對虛擬機監視器(VMM)的分類。VMM一般有三種類型，分別是獨立(Type-1)、宿主(Type-2)和混合(Hybrid)類型。不論是哪一種系統虛擬機模型，只要它能夠提供對Intel VT和AMD-V的支持，都可以在一定程度上減少虛擬化軟件帶來的性能開銷(早期的RISC硬件輔助虛擬化除外)。
虛擬軟件把一個硬件平臺上的ISA翻譯成另一個，以構成系統虛擬機。
Type-1型VMM直接安裝在物理機器上，運行在***特權模式下，而客戶機系統則運行在特權較少的模式上。這種虛擬機在很多方面都是很高效的，但明顯的缺點是要考慮的方面較多(比如各種驅動程序)，所以設計比較復雜，VMware的ESX server就屬于這種類型。
Type-2型VMM類似于在操作系統上安裝的應用程序，VMM可以依賴主機操作系統提供設備驅動和其它底層服務，因此不需要考慮大量的設備驅動問題，VMM體積較小。大家最常用的VMware Workstation和JVM都屬于此類型，這種虛擬機的缺點是會損失一些效率，因為當請求操作系統服務時要通過更多的軟件層次，來回的次數也更多。
混合型是Type-1和Type-2的結合體，在這個類型中VMM和主機操作系統處于平行關系，微軟的Virtual Server 2005R2以及最近非常受大家關注的Xen就是混合型的典范。
#p#
小知識：ISA和ABI
ISA是Instruction Set Architecture的簡寫，譯為指令集體系結構。在這個結構中有兩個部分是和虛擬機密切相關的，一個是用戶指令集(User ISA),另一個是系統指令集(Syetem ISA)。
用戶指令集是應用程序可直接調用的，而系統指令集則是操作系統才能看到的，負責管理硬件資源。ABI是Application Binary Interface的簡寫，譯為應用二進制接口。它包括兩個主要組件，一個是用戶指令集，另一個則是系統調用接口(System Calls)。
#p#
x86體系虛擬化遭遇ISA set缺陷
Popek和Goldberg在1974年發表的那篇論文中給出了一個真正的VMM必須滿足的三個條件：高效性、資源控制和同質性。高效性是指所有的安全指令都可以在本地硬件上直接運行而不需要VMM的干預或仿真，資源控制是指任何客戶機軟件都不能改變它可用的系統資源分配，同質性是指拋開性能略微下降的因素，虛擬機上執行的任何程序的行為必須和在本地機器上運行一樣。這里面我們之所以重點關注高效性，是因為x86指令集系統本身存在問題——有少部分指令不能在以前的虛擬化環節中進行正常VMM陷入，導致指令執行失敗，使得這個條件難以滿足。要理解其中的問題，我們首先要了解CPU虛擬化的基本原理、特權級別和敏感指令。
VMM通常分為三種類型
#p#
CPU虛擬化
在VMM對硬件資源虛擬化的過程中，CPU虛擬化是非常重要的一個環節。CPU虛擬化是為物理機器上的每一個虛擬機提供一個或者多個虛擬CPU(簡稱VCPU)，每個VCPU分時復用物理CPU，在任意時刻一個物理CPU只能被一個VCPU使用。VMM要在整個過程中合理分配時間片以及維護所有VCPU的狀態(資深一些的讀者應該會聯想到現代多任務操作系統中TSS工作機理以及超線程技術中涉及到的上下文切換，是不是有似曾相識的感覺呢？)，當進行VCPU切換時，要保存當前VCPU的狀態，將被調度的VCPU狀態載入物理CPU，可見如何保證VCPU的正確運行和合理調度是CPU虛擬化技術中需要解決的問題。
Type-2型VMM更易使用但是會損失一定效率
#p#
特權級別
大部分的現代計算機體系結構都有兩個或兩個以上的特權級別，用來分隔內核和應用軟件。以x86為例，為了得到更高的保護控制，在x86的保護模式下定義了當前特權級別(Current Previleged Level，簡稱CPL)，一共有四個特級層次(0 to 3)被定義，我們一般稱之為Ring。Ring后面的數字越大特權越小，我們的操作系統一般都運行在Ring0上，而Ring1和2一般用來支持設備驅動，Ring3上面跑的就是應用軟件了。而在現在的x86處理器中，64位架構已經非常普遍，64位CPU因為必須支持頁表模式，所以只有兩個特權級別，我們可以簡單理解為Ring0和Ring3(實際上另有明確定義)，這種模型我們常稱為0/3模型。
系統中有一些關鍵操作指令只能在***特權級別上執行，它們一般被稱為特權指令，特權指令僅僅在當前的特權級別為零時(CPL=0)才會執行。如果在非特權級別上試圖執行特權指令，將生成一個一般保護異常(這通常會生成一個應用程序錯誤)，而非特權指令則可以在任何一個權限級別執行。
#p#
敏感指令中的漏網之魚
在虛擬化世界的VMM模型中，我們可以看到所有的客戶機操作系統都運行在非特權模式下，即非Ring0級。因為Guest OS已經不處在特權級別，所以存在一部分原本應該在特權級別執行但現在因為層級權限不夠必須轉交VMM進行處理的指令，這部分指令就叫敏感指令。
x86的敏感指令中明顯有一部分漏網之魚
而根據Popek和Goldberg的定義，指令集支持虛擬化的前提是：所有敏感指令都是特權指令。很可惜x86指令集不能滿足這個要求，這是它和RISC架構相比的一個不足。
在IBM之類的RISC指令集方面，因為敏感指令全部是特權指令，所以敏感指令的執行都可以被VMM捕獲，而在x86方面，因為有一部分敏感指令不屬于特權指令，變成了非特權指令，而非特權指令在較低的特權級別上是可以直接執行的，也就是說VMM不會處理這些指令。這樣就勢必會帶來問題，試想一個不受虛擬化軟件層控制的指令卻工作在虛擬化層之上，這是怎樣一個情景？x86至少有十幾條敏感指令是不會引發異常的非特權指令，在IA-32指令集中，我們稱這些非特權級別的敏感指令為臨界指令，它們可以分成兩類：
敏感寄存器指令：它們讀取或者修改敏感寄存器和(或者)敏感內存數據區所存放的內容，比如時鐘寄存器、中斷寄存器。
1.SGDT、SIDT、SLDT
2.SMSW
3.PUSHF、POPF
保護系統指令：涉及存儲保護系統、內存或者地址定位系統。
1.LAR、LSL、VERR、VERW
2.POP
3.PUSH
4.CALL、JMP、INT n、RET
5.STR
6.MOV
#p#
臨界指令實例講解
我們用一個實際的例子來解釋x86指令集的虛擬化漏洞。SMSW指令(取機器狀態字的指令)是為了向下兼容老式處理器，這個指令應該由操作系統完成，也就是說需要Ring0才可以，但很可惜它沒有被放在特權指令中。在虛擬化環境中，客戶機操作系統都工作在非特權層次上(一般為Ring1或者Ring3)，前面我們講到非特權指令在較低特權級別時可以不被VMM捕獲而直接執行。
不同的特權級別滿足不同程序運行的需求
客戶機操作系統在執行這個指令時，直接取到的是真實機器的值(假設取值1為保護模式，0為實模式)，現在的VMM一般都工作在保護模式下，如果客戶機操作系統正好運行在實模式下，那么問題就出來了，SMSW取到的值是1，表示系統運行在保護模式下，而不是真正的客戶機操作系統的實模式的返回值0，這顯然是不正確的。
寫在***
講到這里，大家應該對虛擬化和虛擬機的定義以及VMM有了一個整體的認識，也搞明白了x86指令集為什么是不可虛擬化架構，這為我們更好地理解后續要講解的硬件輔助虛擬化奠定了一定的理論基礎。下一次我們就給大家講解傳統CPU虛擬化模型的技術(特權解除和先陷入后模擬)以及軟件CPU虛擬化和硬件CPU輔助虛擬化的解決方法，敬請關注！
MC特約評論員 林昊翔（虛擬化技術愛好者）
虛擬化技術優勢日益體現，不僅大幅度降低了IT支出成本、減少能源浪費，而且還極大地增強了系統整體安全性和可靠性。軟硬件廠商未來可能攜手提高虛擬化產品的自身性能以及提供更豐富的功能。基于主機操作系統的虛擬機產品以及硬件虛擬化技術得到更廣泛應用。硬件廠商在操作模式間的轉換速度、TLB性能、內存虛擬化和I/O虛擬化等方面加以改進和完善；軟件廠商則利用二進制動態翻譯及程序行為分析的技術減小性能開銷，利用內存和存儲的重復刪除技術降低資源開銷。而分布式文件系統和分布式共享內存等技術的引入將有助于打造一個高可用、高容錯的分布式虛擬化軟件平臺，便于虛擬機的部署和動態遷移。
【編輯推薦】
