當前位置：首頁 > 公眾號精選 > Linux閱碼場

Linux系統(tǒng)虛擬化模型及障礙

時間：2021-11-29 15:48:36

關鍵字：模型虛擬化

手機看文章

掃描二維碼
隨時隨地手機看文章

[導讀]作者簡介???王柏生??資深技術專家，先后就職于中科院軟件所、紅旗Linux和百度，現任百度主任架構師。在操作系統(tǒng)、虛擬化技術、分布式系統(tǒng)、云計算、自動駕駛等相關領域耕耘多年，有著豐富的實踐經驗。著有暢銷書《深度探索Linux操作系統(tǒng)》（2013年出版）。謝廣軍??計算機專業(yè)博士...

作者簡介

王柏生資深技術專家，先后就職于中科院軟件所、紅旗Linux和百度，現任百度主任架構師。在操作系統(tǒng)、虛擬化技術、分布式系統(tǒng)、云計算、自動駕駛等相關領域耕耘多年，有著豐富的實踐經驗。著有暢銷書《深度探索Linux操作系統(tǒng)》（2013年出版）。

謝廣軍計算機專業(yè)博士，畢業(yè)于南開大學計算機系。資深技術專家，多年的IT行業(yè)工作經驗?，F擔任百度智能云副總經理，負責云計算相關產品的研發(fā)。多年來一直從事操作系統(tǒng)、虛擬化技術、分布式系統(tǒng)、大數據、云計算等相關領域的研發(fā)工作，實踐經驗豐富。

本文內容節(jié)選自《深度探索Linux虛擬化技術》，已獲得機械工業(yè)出版社華章公司授權。

x86架構CPU虛擬化

Gerald J. Popek和Robert P. Goldberg在1974年發(fā)表的論文“Formal Requirements for Virtualizable[A1] [A2] Third Generation Architectures”中提出了符合虛擬化的3個條件：

（1）等價性，即VMM需要在宿主機上為虛擬機模擬出一個本質上與物理機一致的環(huán)境。虛擬機在這個環(huán)境上運行與其在物理機上運行別無二致，除了可能因為資源競爭或者VMM的干預導致在虛擬環(huán)境中表現上略有差異，比如虛擬機的I/O、網絡等因宿主機的限速或者多個虛擬機共享資源，導致速度可能要比獨占物理機的慢一些。

（2）高效性，即虛擬機指令執(zhí)行的性能與其在物理機上運行相比并無明顯損耗。該標準要求虛擬機中的絕大部分指令無須VMM干預而直接運行在物理CPU上，比如我們在x86架構上通過Qemu運行的ARM系統(tǒng)并不是虛擬化，而是仿真（Emulator）。

（3）資源控制，即VMM完全控制系統(tǒng)資源。由VMM控制協(xié)調宿主機資源給各個虛擬機，而不能由虛擬機控制了宿主機的資源。

陷入和模擬模型

為了滿足GeraldJ. Popek和Robert P. Goldberg提出的滿足虛擬化的3個條件，一個典型的解決方案是Trap andEmulate模型。

一般來說，處理器可以歸結為兩種運行模式：系統(tǒng)模式和用戶模式。相應的，CPU的指令也分為特權指令和非特權指令。特權指令只能在系統(tǒng)模式運行，如果特權指令運行在用戶模式就將觸發(fā)處理器異常。操作系統(tǒng)將內核運行在系統(tǒng)模式，因為內核需要管理系統(tǒng)資源，需要運行特權指令，而普通的用戶程序則運行在用戶模式。

在虛擬化場景下，虛擬機的用戶程序仍然運行在用戶模式，但是虛擬機的內核將運行在用戶模式，這種方式稱為Ring Compression。在這種方式下，虛擬機中的非特權指令直接運行在處理器上，滿足了Popek和Goldberg提出的虛擬化標準中高效的要求，即指令的大部分無須VMM干預直接在處理器上運行。但是，當虛擬機執(zhí)行特權指令時，因為是在用戶模式執(zhí)行特權指令，將觸發(fā)處理器異常，從而陷入到VMM中，由VMM代理虛擬機完成系統(tǒng)資源的訪問，即所謂的模擬（emulate）。如此，又滿足了Popek和Goldberg提出的虛擬化標準中VMM控制系統(tǒng)資源的要求，虛擬機將不會因為可以直接運行特權指令而修改宿主機的資源，從而破壞宿主機的環(huán)境。

x86架構虛擬化的障礙

Gerald J. Popek和Robert P. Goldberg指出，修改系統(tǒng)資源的，或者在不同模式下行為有不同表現的，都屬于敏感指令。在虛擬化場景下，VMM需要監(jiān)測到這些敏感指令。一個支持虛擬化的體系架構的敏感指令都屬于特權指令，即在非特權級別執(zhí)行這些敏感指令時，CPU會拋出異常，進入VMM的異常處理函數，從而實現了控制VM訪問敏感資源的目的。

但是，x86架構恰恰不能滿足Gerald J. Popek和Robert P. Goldberg定義的這個準則，且并不是所有的敏感指令都是特權指令，有些敏感指令在非特權模式下執(zhí)行時并不會拋出異常，此時VMM就無法攔截或者處理VM的行為。以修改FLAGS寄存器中的IF（interrupt flag）為例，我們首先使用指令pushfd將寄存器FLAGS的內容壓到棧中，然后將棧頂的IF清0，最后使用popf指令從棧中恢復FLAGS寄存器。如果將虛擬機內核運行在ring 1，x86的CPU并不會拋出異常，而只是默默地忽略指令popfd，因此虛擬機關閉IF的目的并沒有生效。

有人提出半虛擬化的方式，即修改Guest的代碼，但是這不符合虛擬化的透明準則。后來，人們提出了二進制翻譯的方式，包括靜態(tài)翻譯和動態(tài)翻譯。靜態(tài)翻譯就是在運行前，掃描整個可執(zhí)行文件，對敏感指令進行翻譯，重新形成一個新的文件。靜態(tài)翻譯是有其局限性的，必須提前處理，而且有些指令只有在運行時才產生的副作用，無法靜態(tài)處理。于是，動態(tài)翻譯應運而生，即在運行時以代碼塊為單元動態(tài)地修改二進制代碼。動態(tài)翻譯在很多VMM中得到應用，而且優(yōu)化的效果非常不錯。

VMX擴展

雖然程序員們從軟件層面采用了多種方案去解決x86架構在虛擬化方面的問題，但是軟件層的解決方案除了額外的開銷外，也給VMM的實現帶來了巨大的復雜性。于是，Intel嘗試從硬件層面解決這個問題。Intel并沒有將那些非特權的敏感指令修改為特權指令，因為并不是所有的特權指令都需要Trap and Emulate。我們舉個典型的例子，每當操作系統(tǒng)內核切換進程時，都會切換cr3寄存器，使其指向當前運行進程的頁表。當使用影子頁表進行GVA到HPA的映射時，需要捕獲Guest的每一次設置cr3寄存器的操作，VMM模塊使其指向影子頁表。而當啟用了硬件層面的EPT支持后，cr3仍然指向Guest的進程頁表，無須捕捉Guest設置cr3寄存器的操作，也就是說，雖然寫cr3寄存器是特權指令，但是其不需要陷入VMM。

Intel開發(fā)了VT技術支持虛擬化，為CPU增加了Virtual-Machine Extensions，簡稱為VMX。一旦啟動了CPU的VMX支持，CPU將提供2種運行模式：VMX Root Mode和VMX non-Root Mode，每一種模式都支持ring0 ~ ring3。VMM運行在VMX RootMode，除了支持VMX外，VMX Root Mode和普通的模式并無本質區(qū)別。VM運行在VMX non-Root Mode，Guest無須再采用Ring Compression方式，Guest kernel可以直接運行在VMX non-Root Mode的ring0，如圖1所示。

圖1 VMX運行模式

處在VMX RootMode的VMM可以通過執(zhí)行CPU提供的虛擬化指令VMLaunch切換到VMX non-Root Mode，因為這個過程相當于進入Guest[3] ，所以通常也被稱為VM entry。當Guest內部執(zhí)行了敏感指令，比如某些I/O操作后，將觸發(fā)CPU發(fā)生陷入的動作，從VMX non-Root Mode切換回VMX Root Mode，這個過程相當于退出VM，所以也稱為VM exit。然后VMM將對Guest 的操作進行模擬。相比于Ring Compression方式，即將Guest的內核也運行在用戶模式（ring 1 ~ ring 3）的方式，支持VMX擴展的CPU[4] ：

（1）運行于Guest模式時，Guest用戶空間的系統(tǒng)調用直接陷入Guest模式的內核空間，而不是再陷入到Host模式的內核空間。

（2）對于外部中斷，因為需要讓VMM控制系統(tǒng)的資源，所以處于Guest模式的CPU收到外部中斷，則觸發(fā)CPU從Guest模式退出到Host模式，由Host內核處理外部中斷。處理完中斷后，再重新切入Guest模式。為了提高I/O效率，Intel支持外設透傳模式，在這種模式下，Guest可以不必產生VM exit，“設備虛擬化”一章將討論這種特殊方式。

（3）不再是所有的特權指令都會導致處于Guest模式的CPU發(fā)生VM exit，僅當運行敏感指令時才會導致CPU從Guest模式陷入Host模式，因為有的特權指令并不需要由VMM介入處理。

如同一個CPU可以分時運行多個任務一樣，每個任務有自己的上下文，由調度器在調度時切換上下文，從而實現同一個CPU同時運行多個任務。在VMX擴展下，同一個物理CPU“一人分飾多角”，分時運行著Host及Guest，在不同模式間按需切換，因此，不同模式也需要保存自己的上下文。為此，VMX設計了一個保存上下文的數據結構：VMCS。每一個Guest都有一個VMCS實例，當物理CPU加載了不同的VMCS時，將運行不同的Guest，，如圖2所示。

圖2 多個Guest切換

VMCS中主要保存著兩大類數據，一類是狀態(tài)，包括Host的和Guest的，另外一類是控制Guest運行時的行為。

（1）Guest-state area，保存虛擬機狀態(tài)的區(qū)域。當發(fā)生VM exit時，Guest的態(tài)保存在這個區(qū)域；當VM entry時，這些狀態(tài)將被裝載到CPU中。這些都是硬件層面的自動行為，VMM無須編碼干預。

（2）Host-state area，保存宿主機狀態(tài)的區(qū)域。當發(fā)生VM exit時，CPU自動從VMCS裝載這些狀態(tài)到物理CPU；當VM entry時，CPU自動將狀態(tài)保存到這個區(qū)域。

（3）VM-exit information fields。當虛擬機發(fā)生VM exit時，VMM需要知道導致VM exit的原因，然后才能對癥下藥，進行相應的模擬操作。為此，CPU會自動將Guest退出的原因保存在這個區(qū)域，供VMM使用。

（4）VM-execution control fields。這個區(qū)域中的各種字段控制著虛擬機運行時的一些行為，比如設置Guest運行時訪問cr3時是否觸發(fā)VM exit；控制VM entry與exit時的行為的VM-entry control fields和VM-exitcontrol fields。我們不再一一列出細節(jié)，讀者如有需要可以查閱Intel手冊。

在創(chuàng)建VCPU時，KVM模塊將為每個VCPU申請一個VMCS，每次CPU準備切入Guest模式時，將設置其VMCS指針指向即將切入的Guest對應的VMCS實例：

commit 6aa8b732ca01c3d7a54e93f4d701b8aabbe60fb7

[PATCH] kvm: userspace interface

linux.git/drivers/kvm/vmx.c

static struct kvm_vcpu *vmx_vcpu_load(structkvm_vcpu *vcpu)

{

u64phys_addr = __pa(vcpu->vmcs);

int cpu;

cpu =get_cpu();

…

if(per_cpu(current_vmcs, cpu) != vcpu->vmcs) {

…