原文：http://blog.csdn.net/jmilk/article/details/51824935
全虛擬化
不需要對GuestOS操作系統軟件的源代碼做任何的修改，就可以運行在這樣的VMM中
在全虛擬化的虛擬平台中，GuestOS並不知道自己是一台虛擬機，它會認為自己就是運行在計算機物理硬件設備上的HostOS。因為全虛擬化的VMM會將一個OS所能夠操作的CPU、內存、外設等物理設備邏輯抽象成為虛擬CPU、虛擬內存、虛擬外設等虛擬設備后，再交由GuestOS來操作使用。這樣的GuestOS會將底層硬件平台視為自己所有的，但是實際上，這些都是VMM為GuestOS制造了這種假象。
全虛擬化又分為：軟件輔助的全虛擬化 & 硬件輔助的全虛擬化。
軟件輔助的全虛擬化
軟件輔助全虛擬化架構圖： 
在Intel等CPU廠商還沒有發布x86 CPU虛擬化技術之前，完全虛擬化都是通過軟件輔助的方式來實現的。而軟件輔助的全虛擬化主要是應用了兩種機制：
1. 特權解除(優先級壓縮)：從上述的軟件輔助全虛擬化架構圖中可以看出，VMM、GuestOS、GuestApplications都是運行在Ring 1-3用戶態中的應用程序代碼。當在GuestOS中執行系統內核的特權指令時，一般都會觸發異常。這是因為用戶態代碼不能直接運行在核心態中，而且系統內核的特權指令大多都只能運行在Ring 0核心態中。在觸發了異常之后，這些異常就會被VMM捕獲，再由VMM將這些特權指令進行虛擬化成為只針對虛擬CPU起作用的虛擬特權指令。其本質就是使用若干能運行在用戶態中的非特權指令來模擬出只針對GuestOS有效的虛擬特權指令，從而將特權指令的特權解除掉。
缺點：但是特權解除的問題在於當初設計標准x86架構CPU時，並沒有考慮到要支持虛擬化技術，所以會存在一部分特權指令運行在Ring 1用戶態上，而這些運行在Ring 1上的特權指令並不會觸發異常然后再被VMM捕獲。從而導致在GuestOS中執行的特權指令直接對HostOS造成了影響(GuestOS和HostOS沒能做到完全隔離)。
針對這個問題，再引入了陷入模擬的機制。
陷入模擬(二進制翻譯)：就是VMM會對GuestOS中的二進制代碼(運行在CPU中的代碼)進行掃描，一旦發現GuestOS執行的二進制代碼中包含有運行在用戶態上的特權指令二進制代碼時，就會將這些二進制代碼翻譯成虛擬特權指令二進制代碼或者是翻譯成運行在核心態中的特權指令二進制代碼從而強制的觸發異常。這樣就能夠很好的解決了運行在Ring 1用戶態上的特權指令沒有被VMM捕獲的問題，更好的實現了GuestOS和HostOS的隔離。
簡而言之，軟件輔助虛擬化能夠成功的將所有在GuestOS中執行的系統內核特權指令進行捕獲、翻譯，使之成為只能對GuestOS生效的虛擬特權指令。但是退一步來說，之所以需要這么做的前提是因為CPU並不能准確的去判斷一個特權指令到底是由GuestOS發出的還是由HostOS發出的，這樣也就無法針對一個正確的OS去將這一個特權指令執行。
直到后來CPU廠商們發布了能夠判斷特權指令歸屬的標准x86 CPU之后，迎來了硬件輔助全虛擬化。
硬件輔助的全虛擬化
硬件輔助全虛擬化主要使用了支持虛擬化功能的CPU進行支撐，CPU可以明確的分辨出來自GuestOS的特權指令，並針對GuestOS進行特權操作，而不會影響到HostOS。
從更深入的層次來說，虛擬化CPU形成了新的CPU執行狀態 —— * Non-Root Mode& Root Mode* 。從上圖中可以看見，GuestOS運行在Non-Root Mode 的Ring 0核心態中，這表明GuestOS能夠直接執行特卻指令而不再需要 特權解除 和 陷入模擬 機制。並且在硬件層上面緊接的就是虛擬化層的VMM，而不需要HostOS。這是因為在硬件輔助全虛擬化的VMM會以一種更具協作性的方式來實現虛擬化 —— 將虛擬化模塊加載到HostOS的內核中，例如：KVM，KVM通過在HostOS內核中加載KVM Kernel Module來將HostOS轉換成為一個VMM。所以此時VMM可以看作是HostOS，反之亦然。這種虛擬化方式創建的GuestOS知道自己是正在虛擬化模式中運行的GuestOS，KVM就是這樣的一種虛擬化實現解決方案。
半虛擬化
需要對GuestOS的內核代碼做一定的修改，才能夠將GuestOS運行在半虛擬化的VMM中。
半虛擬化通過在GuestOS的源代碼級別上修改特權指令來回避上述的虛擬化漏洞。
修改內核后的GuestOS也知道自己就是一台虛擬機。所以能夠很好的對核心態指令和敏感指令進行識別和處理，但缺點在於GuestOS的鏡像文件並不通用。
具體的x86架構CPU解析，請參考虛擬化的發展歷程和實現方式