OKL4虚拟化技术跟踪

这篇博客准备介绍OKL4的研究进展，本文的内容主要根据我个人阅读《OKL4_LongPaper_2010_HW_VM》这篇文章之后的理解，我也根据这篇论文的内容做了一些实验，奈何此论文涉及内容太广，有一些arm硬件我也不太熟，而且由于时间有限，只能做一部分它提到的实验，没做过的实验我会介绍我的分析和理解，如果有问题希望读者批评指正。

这篇论文不会对所涉及的每一个虚拟化名词和技术都展开介绍，读者可以自行Google或者参看ARM文档，我建议读者遇到不懂的部分先通过Google理解大致含义再通过阅读ARM文档深入理解，因为ARM文档对某些内容的叙述实在太不友好，虽然全面但是不能突出重点，内容又多又难理解（其实我想说超级难懂）。

好，闲言少叙，咱们直接进入正题。

总体介绍

这部分主要介绍这篇论文的研究动机（motivation）、相关机构的研究情况（related work）。

首先，这篇文章研究的内容是基于arm最近推出的对硬件虚拟化的支持（2010年），硬件的支持使基于arm平台的虚拟化逐渐向KVM靠拢。以前，没有硬件支持的条件下，由于传统的trap-and-emulate的方式开销过大，人们更倾向于用para-virtualization的方式在arm平台做虚拟化，para-virtualization的方式虽然提高了性能，但是它需要修改guest os的源码，这样做的弊端我在对NOVA的分析中已经介绍过了，读者可以去翻阅一下。有一个事实是，即使有硬件支持的条件下，full-virtualization的性能也不如para-virtualization，如果读者曾经做过虚拟化方面的编码实现，可以思考一下为什么这样。

在讨论arm新增加的virtualization extension之前，我们知道对硬件虚拟化的支持主要有intel的VT-x和AMD的AMD-V，它们两个十分类似，所以这里我们只介绍VT-x，看看它对虚拟化做了怎样的支持（为后面做对比）。

• 将cpu的模式分为hypervisor（VMX root operation）和guest（VMX non-root operation）。
• 可以配置一些敏感指令和事件，让它们产生trap。
• （新增）提供扩展页表（EPT，extended page table），通过这个页表在硬件上完成second-stage of translation，其实就是常说的二级页表翻译。
• （新增）在TLB上新增加了VM tag去标识每一个虚拟机，这样可以避免每次VM-entry和VM-exit时的TLB flush操作（其实还增加了VPID，去标识VM里虚拟进程的进程id）。
• （新增）在Intel的 VT-d里增加了对DMA操作的支持，而且是一种安全的DMA（具体怎么实现的安全读者可以自己分析下）。

Inter-VM Communication

不知道读者有没有这样的疑问，为什么不同的guest os需要通信呢？这里引用论文作者的原话“One of the main motivation for communication between guests is to allow a single device to be shared between multiple guests”。作者还举了一个例子，microvisor作为运行在hyp mode的host os，在它的上面运行guest os和一些device driver，然后这些guest os通过hosted device driver与这些外设进行通信，实际上相当于guest os与host os之间的通信。其实这里主要的原因就是有一些外设直接映射给某一个guest os使用了，这个guest os里面有这个设备的驱动，其他guest os想要用这个设备需要和这个guest os进行通信。

guest os运行在non-secure world的kernel mode，其实这个kernel mode是non-secure world的EL1（EL1是processor的特权级，类似于intel下的ring0-ring3）。如何实现guest os之间的通信呢？ARM新增的virtualization hardware feature其中就增加了一条HVC指令，这个HVC指令其实是一个hypercall，它可以使guest os从kernel mode陷入到hyp mode（EL2），两者之间通过寄存器传递参数和返回结果。除了寄存器以外，还可以通过一块在hypervisor里的buffer或者共享页面来通信。其中这里比较关键的是一个VM-ID，可以通过这个VM-ID去标识不同的guest os，这样通信的时候标识通信双方就容易多了。

作者根据以上内容设计了一套通信API，简单来说分为三部分：

1. 获取VM-ID
2. 发送信息
3. 接受信息

接下来作者还加入了一个IRQ唤醒机制，当有消息要发送给某一个guest os时，hypervisor会向这个guest os发一个vIRQ，这样就避免了guest os不断询问hypervisor是否有消息发送给他，而只需要等待接收中断就行了。作者还描述了他设计的一个高效的页面分享算法，其实很简单，一个guest设置一个页面位共享页面，然后通过一个hypercall调用一个共享页面的api，返回一个share id。其他的guest可以通过这个share id把这个共享页面map到自己的地址空间，在这里面他又加入了一些锁机制，保证对共享页面的访问不会出错。