开发者MJ Pooladkhay为Redox OS完成Virtio-FS驱动并实现Cloud Hypervisor启动

我是 MJ Pooladkhay，过去几个月我一直在为 Redox OS 构建 Virtio-FS 驱动，最近又开始让 Redox 跑在 Cloud Hypervisor 上。该驱动已经合并进基础仓库，Redox 的大多数驱动和系统组件都放在那里。让 Redox 能在 Cloud Hypervisor 上启动到 shell 的内核、bootloader 和驱动改动也已经合并（详情见下文）。

这两件事各自都很有意思，但它们实际上是一项更大工作的第一步，这个工作有两个方向：

guest 侧的工作由 NGI Zero Commons 和 NLnet 慷慨资助，属于 Virtualized Redox 拨款项目的一部分。

如今大多数面向互联网的软件都运行在虚拟机里，无论是在云端还是靠近用户的边缘服务器上。Web 服务器、数据库、API 后端和微服务整天都在处理来自陌生人的输入，而这正是基于内存安全微内核的操作系统最能发挥优势的地方：

这就是项目在其开发优先级中设定的方向：让 Redox 成为 Web 服务的安全宿主，首先作为私有或边缘服务器，最终成为多租户云服务器，每个租户与其他租户相互隔离。

我所知道的理解 hypervisor 的最简单方式，是把它看作一个操作系统，而它的进程就是操作系统。一个进程直接在 CPU 上运行，直到它需要内核——为了系统调用、缺页或时钟中断——然后内核接管一小会儿。guest OS 以同样的方式直接在 CPU 上运行，直到它做了某件只有 hypervisor 才有权处理的事情。那一刻会发生“VM exit”，控制权被转移给 hypervisor（类似于系统调用将控制权转移给 OS 内核）。在 Linux 上，宿主内核中的 KVM 负责处理，要么自己处理，要么转交给虚拟机监视器（VMM）——一个普通进程，比如 Cloud Hypervisor 或 QEMU。我在个人博客之前的一篇文章中梳理了这背后的理论，以及为什么 x86 需要新硬件（VT-x 和 AMD-V）才能实现它。

从 Redox 的角度看，虚拟机的启动方式很像笔记本电脑。虚拟 CPU 从固件开始运行，固件从磁盘加载 bootloader，bootloader 再移交给内核。运行的是与真实硬件上相同的代码，原生执行，内核照常处于超级visor 模式（x86 上的 ring 0）。

Redox 所做的大部分事情都不会离开 guest。系统调用、上下文切换和缺页都由 Redox 内核自己处理，hypervisor 甚至看不到它们。

内存比裸机要多几步，因为现在有两个内核各自都认为自己拥有它。Redox 的页表将 guest 虚拟地址（GVA）转换为 guest 物理地址（GPA），也就是 Redox 认为在 RAM 中的地址。但 guest RAM 实际上只是 VMM 在自己的地址空间中分配的一大块内存，VMM 告诉 KVM 哪一部分对应 guest RAM 的哪个范围（一个 memslot）。所以每个 GPA 同时也是 Cloud Hypervisor 进程中的一个 host 虚拟地址（HVA），宿主内核的页表再把它转换为 host 物理地址（HPA），也就是 RAM 中的实际位置：

GVA --[Redox 的页表]--> GPA --[KVM memslots]--> HVA --[宿主页表]--> HPA

如果每次内存访问都要走完这一整套，会慢得让人难以忍受，所以 KVM 把 GPA 到 HPA 这一段合并成一步。它构建嵌套页表，将 guest 物理地址直接映射到 host 物理地址，并在 guest 访问内存时惰性填充。然后 CPU 在硬件中同时遍历 Redox 的页表和嵌套页表，并将结果缓存到 TLB 中。Redox 可以自由管理自己的页表，只有访问尚未映射的 guest 内存时才会触发 exit。

HVA 这一步有一个不错的副作用：由于 guest RAM 只是 VMM 中的一个普通映射，它可以与其他宿主进程共享。这就是 virtiofsd 能直接从 guest 内存中读取 Virtio-FS 请求的原因，也是共享目录要求 guest 内存必须共享的原因。

设备才是 hypervisor 真正体现价值的地方，因为 guest 看到的每个设备都是虚构出来的。有些是真实硬件的模拟，比如 8259 中断控制器、可编程间隔定时器（PIT）、串口或每个 CPU 的本地 APIC，对它们的每次寄存器访问都是一次 VM exit，由 hypervisor 将其转化为相应行为。另一些是 VirtIO 设备，它们根本不假装自己是硬件，而是通过共享内存中的队列与宿主通信。中断也是虚构的。宿主保留真实的中断，guest 只收到 hypervisor 代表其虚拟设备和定时器注入的中断。如果 hypervisor 不模拟某个设备，就没有人触发它的中断（记住这一点，后面讲 ping 的故事时会用到）。

简而言之，CPU、它的时间戳计数器（TSC）和内存是真实的，其他一切都是虚拟的。有趣的问题是你得到哪些虚拟设备，而这正是云 hypervisor 和 QEMU 分道扬镳的地方。

到目前为止，Redox 要么运行在 QEMU 上，要么运行在物理硬件上。在这两种情况下，它都依赖于可以追溯到最初 IBM PC/AT 的设备：一对 8259 中断控制器、PIT、PS/2 键盘控制器等等。这些即使在真实硬件上也属于遗留设备。现代机器以及 Linux 等操作系统通过 I/O APIC 路由中断，并用每个 CPU 的本地 APIC 定时器来计时。Redox 之所以一直使用旧设备，主要是因为它不支持建立其替代品所需的 ACPI 部分。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）