论文的原文在这里 Dune: Safe User-level Access to Privileged CPU Features

1. Introduction

Dune 的目标是让用户态程序直接使用硬件特性（例如，获得更好的硬件加速等），不过所谓的 “直接” 还是在虚拟化的环境中。Dune 利用现代 CPU 的虚拟化功能，提供给用户一个 进程的抽象， 而不是一个 虚拟机的抽象。

Dune 是一个内核模块，可以在需要的时候加载到标准的 linux 内核中。 于是一个普通进程可以进入 “Dune Mode”，在这个模式下的进程可以直接访问页表、中断、系统调用表等等。

特点：

  • Dune 进程是一个普通的 linux 进程，唯一的区别是它用 VMCALL 指令进入系统调用。
  • Dune 内核模块只提供进程级别的抽象，因此相对于 KVM 来说要简单得多。

3. Kernel Support for Dune

Dune mode 下的进程运行在 VMX non-root 模式，可以安全的访问特权级硬件。然后看一下 Dune 的整个架构图。

Dune Architecture {:height=“300” width=“300”}

如果说前面 1、2 小节读下来仍然云里雾里的话，一看到这个图立刻觉得特别清晰了，因为太像 KVM 的架构了！ 同样也是利用 CPU 提供的 VT-x 技术，Dune 更像是一个轻量级的 KVM。

在后续的章节中，作者也提到了 Dune 项目的原型就是在 KVM 的基础上修改的，特别是对 VT-x 操作的部分。

结合最近在网上看到一些关于 “容器和虚拟机谁会取代谁” 的论调，其中有一句话值得品味：

当Intel通过 VT-x 指令集在芯片中直接提供Hypervisor所特有的众多功能时，Hypervisor 的丧钟就已经敲响

虽然这句话危言耸听不太靠谱，但是思考一下：如果说运行在容器中的进程缺少像虚拟机这样的强隔离的话，那么加上 Dune 或者 gvisor 这样的沙箱，是不是就可以取代 KVM 了呢 ？

与 VMM 的区别

作者列举了 4 点：

  • 半虚拟化里面的 Hypercall 概念在 Dune 里面直接当 system call 用了。
  • VMM 需要模拟很多设备来支持 GuestOS，而在 Dune 里，这些设备直接通过 OS 来支持。
  • Dune 仅仅需要更少的 VMCS 结构来保存 VT-x 的状态。
  • Dune 里 process 的内存地址空间的隔离，但也会 share 很多东西（进程的多个线程可以分别进入 Dune mode）。