全/半虛擬化、硬體/軟體輔助的全虛擬化之間的區別與聯絡
全虛擬化
不需要對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有效的虛擬特權指令，從而將特權指令的特權解除掉。
缺點
針對這個問題，再引入了陷入模擬的機制。
陷入模擬(二進位制翻譯)：就是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解析，請參考虛擬化的發展歷程和實現方式