虚拟化技术 - CPU虚拟化

Tianyiyun · · 441 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

本文分享自天翼云开发者社区《虚拟化技术 - CPU虚拟化》,作者:谢****悦

物理机器是由CPU,内存和I/O设备等一组资源构成的实体。虚拟机也一样,由虚拟CPU,虚拟内存和虚拟I/O设备等组成。VMM(VM Monitor)按照与传统OS并发执行用户进程的相似方式,仲裁对所有共享资源的访问。本文将分别讨论CPU虚拟化、内存虚拟化和I/O虚拟化技术的原理和实现。

在虚拟化的平台上,虚拟机(guest VM)所使用的多个虚拟CPU(以下称vCPU)可能是共享同一个物理CPU(以下称pCPU)的。VMM负责vCPU的调度,当一个vCPU被调度到获得pCPU的使用权后,基于该vCPU运行的guest OS又可以调度OS中的各个线程/进程了。也就是说,guest OS中的各个线程/进程分时复用了vCPU,而各个vCPU又分时复用了pCPU。

为了从硬件上提供对vCPU调度和切换的支持,Intel推出了被称为VT-x(Virtualization Technology for x86)的CPU虚拟化扩展技术,用户可通过VMXON/VMXOFF指令打开/关闭这个功能。和Intel亦敌亦友的AMD也推出了被称为AMD-V的对应技术。

在Linux中,从用户空间trap到内核空间可以通过system call或者interrupt/exception。以system call基于x86的实现为例,早期x86提供的trap方法是int 0x80这样的software interrupt机制,而后改成了SYSENTER/SYSEXIT的指令对,现在则已经被速度更快的SYSCALL/SYSRET取代了。

类似地,在VT-x中,从guest VM进入VMM(这个过程被称为VM exit)通常有三种方式:

  1. 执行VMCALL指令,这种方式被称为hyper call,跟执行SYSCALL指令实现的system call原理差不多。
  2. 发生了硬件中断或软件异常。
  3. guest VM执行了一些敏感指令。有一些敏感指令并不会产生VM exit,比如SYSENTER;有一些敏感指令则可以根据下面将要介绍的VM executation control fields配置来选择是否产生VM exit。

进入VMM就意味着从non-root mode进入了root mode,反之,从VMM返回guest VM(这个过程被称为VM entry)则是重新回到了non-root mode,mode的切换意味着上下文(context)的保存和恢复。

上下文其实是个难以定义的概念,它是从CPU的角度引出的,简单地说,上下文就是程序(进程/中断)运行时所需要的寄存器的最小集合,这些寄存器的后面可能代表着程序运行的一类资源。

上下文切换是指程序从一种状态切换到另一种状态(比如从用户态切换到内核态),或者从一个程序切换到另一个程序(比如进程切换)时,导致上下文相关寄存器的值变化的行为。对于上下文切换时不需要改变的寄存器,也可以说它不是该程序的上下文。

VMCS

在Linux中,一个进程的相关信息保存在task_struct中。虚拟机的上下文比进程的上下文更为复杂,在VT-x中,由VMCS(Virtual-Machine Control data Structures)负责保存vCPU需要的相关状态和上下文信息。

VMCS在使用时需要和pCPU绑定。一个pCPU可以对应多个vCPU,而一个vCPU对应一个VMCS,但在任意给定时刻,一个pCPU上只能运行一个vCPU(就像在多线程调度中,某一时刻,一个CPU上只能运行一个线程一样)。

因此,一个pCPU只能绑定一个VMCS,一个VMCS也只能与一个pCPU绑定,可分别通过VMPTRLD/VMCLEAR指令建立/解除两者的绑定关系。VMCS存放在内存中,一个VMCS占据4KB大小,由6个区域组成:

  1. Guest state area,用于保存CPU在non-root mode下运行时的状态。当发生VM exit的时候,CPU将自己当前的状态保存到guest state area中,当发生VM entry的时候,guest state area保存的状态将被自动加载到CPU中。

其实也不用一口气将所有寄存器的值都恢复,反正都是保存在VMCS中的,可以等到该寄存器真正被guest使用到时再恢复,这就是Lazy Save/Restore,其基本思想是尽量将寄存器的保存/恢复延迟到最后一刻,减少无用功,提高上下文切换的效率。这种思想在Linux的实现中也比比皆是,比如copy on write, demand paging等,拖延症也不见得是件坏事哈。

  1. Host state area,用于保存CPU在root mode下运行时的状态。需要保存的寄存器和guest state area是差不多的,但是保存/恢复的过程是刚好反过来的。
  2. VM executation control fields,用于控制non-root模式下CPU的行为。出于优化的目的,VMM可以让某些敏感指令不产生VM exit,以减少mode切换带来的上下文开销,而这就是由VM execution control来实现的。

比如读取timestamp的RDTSC指令,在一些延时函数的实现中,该指令会被频繁使用,如果每次guest执行该指令的时候都trap到VMM,那系统开销就太大了,这时VMM可以选择每隔一段时间读取物理CPU真实的 timestamp值,然后填写guest 的timestamp虚拟寄存器,来达到模拟RDTSC指令的效果。

  1. VM exit control fields,用于规定VM exit时CPU的行为,比如是否应答外部中断。
  2. VM exit information fields。VMM除了通过VM exit control fields来控制VM exit的行为,还需要知道VM exit的相关信息(比如trap的具体原因),这些信息就是保存在VM exit information fields中的。
  3. VM entry control fields,用于控制VM entry的过程,比如后续的文章要介绍的中断注入。

VM executation control可理解为what to trap,就是哪些event会引起trap,哪些不会。VM exit control可理解为how to trap,VM exit information则可理解为why to trap。读写VMCS这段内存空间需要使用专门的VMREADVMWRITE指令。

小结一下,一个完整的VT-x使用流程是这样的:首先需要通过CPUID指令检查当前CPU是否支持虚拟化扩展。如果支持,则通过VMXON使能VT-x,建立VMCS并通过VMPTRLD绑定物理CPU。

 

441 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传