目前业界云平台一般会提供 Windows 虚拟机和 Linux 虚拟机，用户可以在这些虚拟机上部署符合 Windows生态和 Linux 生态的服务和应用。MacOS 作为 Apple 生态的基本操作系统，MacOS 虚拟化的实现将会为使用 Apple 生态的用户带来很大的便利，如直接在 MacOS 的虚拟机上进行测试、构建iOS 应用，甚至使用 MacOS 虚拟机作为办公环境等。

目前社区对于 Intel x86  Mac mini 平台的 MacOS虚拟化方案已经比较成熟，随着 2020年 Apple 推出自研的 ARM64 M1芯片，Mac mini 增加了对 ARM64 平台的支持，后续 Apple 将逐渐从 Intel x86 芯片转向自研的 ARM64 芯片。相对于 Intel x86 平台，社区对 ARM64 平台的 MacOS 虚拟化方案还在探索和起步阶段，于是字节跳动 STE 团队和 App Infra 团队率先进行了深入的研究，本文将与大家分享针对采用 ARM64 M1 芯片的 Mac mini M1 机型虚拟化方案的探索和实现。

Mac mini 虚拟化是指在一台 Mac mini 物理机上模拟出多个互相隔离的 Mac mini 虚拟机，使得每个虚拟机用户都认为自己在一台真正的物理机上以独占的方式运行。

Linux

Asahilinux 对 M1 机型上的硬件设备做了足够多的逆向工程分析，并根据推出来的硬件逻辑来尝试实现linux下的各设备驱动，目前已实现了对 M1 机型的基本支持，其中对 M1 GPU的支持也在不断完善中。Asahilinux这部分工作也在不断的合入Linux upstream。

我们采用Asahilinux作为运行在M1裸机上的操作系统。依赖Asahilinux，我们可以获得M1 的 linux 运行时物理机环境，并以此为基础逐步构建和实现M1虚拟化所需的虚拟化软件栈。

QEMU

QEMU 作为机型/系统模拟的常用软件，构造了机型模拟的基本框架，并在此基础上提供了不同平台上很多具体机型的模拟实现，比如 x86 平台的 piix 和 Q35 机型，ARM 的 virt 和 raspi2 等。在 M1 机型的虚拟化中我们需要基于 ARM64 通用机型，构造一个新的 M1 机型，并集成到 QEMU 提供的机型模拟框架中。

QEMU 提供的基本模拟方式是纯软件的，即对于每一条虚拟机内部执行的指令都需要退出到 QEMU 的上下文来翻译执行(TCG)，该方式性能很低。KVM 可以帮助我们解决 QEMU 纯软件模拟带来的低性能问题。

KVM

KVM 作为 Linux 下支持虚拟化的内核模块，将虚拟化场景下的硬件加速功能通过 ioctl 的方式导出给QEMU使用。在 KVM 的支持下，虚拟机内部的常用指令将不再需要退出到QEMU来模拟执行，而是在虚拟机的 CPU 上下文中直接执行，只有个别特权指令才需要退出到物理机上，由物理机来具体执行。对于虚拟机的内存访问，也不再需要 QEMU 进行页表翻译，而是直接依赖硬件实现的两级页表翻译机制（虚拟机内部页表实现 Guest Virtual Address向Guest Physical Address的转化，使用stage2 page table 实现 Guest Physical Address向Host Physical Address的转化），从而实现内存的快速访问。

了解了基本的虚拟化软件栈后，我们开始考虑如何模拟一台真正的 Mac mini M1。那么，模拟 M1 机型包括模拟哪些内容呢？

3）Cluster 内和 Cluster 间的 Fastipi 通信机制；

区别于 M1 物理机，M1 虚拟机的存储和网络主要采用虚拟化场景下常见的 virtio-pci 设备，如 virtio-blk / virtio-net 设备等。我们需要在模拟的 M1 机型上插上 PCIE 的线，其下接各种 PCI / PCIE 设备。另外，为了让设备的中断能够顺利分配、触发并递送到目的 VCPU 中，还需要模拟 M1 的中断控制器 AIC。

AIC 是 M1 Apple Interrupt Controller 的简称， 主要负责中断掩码/中断状态设置、接受/递送中断等。对 AIC 的模拟主要是对上述的功能的模拟，可以通过 Asahilinux 的 AIC 驱动部分的代码逻辑来推断出 AIC 具体地址空间的含义，从而实现 AIC 的模拟。对 AIC 的模拟中我们使用了 MMIO（Memory-Mapped IO） 空间来实现对 AIC 内部相关硬件地址的访问逻辑。

对 M1 新插上的 PCIE 总线的模拟基于 QEMU 提供的通用 PCIE 线——gpex-pcihost 来实现，在通用的 gpex-pcihost 模型的基础上，我们需要根据 M1 的 DTB 文件来制定 M1 PCIE 总线配置空间和bar空间，以及其下 PCI 设备的 PCI 配置空间和 Bar 地址空间范围。

整体的中断设计如下：

将模拟的 M1 PCIE （gpex-pcihost ）总线的 4 个 gpio_out pin 依次连接到 AIC 的 gpio-in pin 上去。gpex-pcihost 通过该连线传递中断给AIC；

AIC 有 cpu_num 个 gpio_out pin ，这些引脚分别连接到各个 CPU 上，AIC 通过该连线递送中断给 CPU。

至此，我们已经在 QEMU 层面实现了对 M1 的 CPU、PMGR、AIC、PCIE 总线等设备的基本模拟，可以通过 QEMU 命令在 PCIE 线上插上所需的 PCI 设备，如 virtio-blk、virtio-net 等，来尝试启动 MacOS 虚拟机了。

既然已经完成了对 M1 虚拟机所需要的基本组件的模拟，接下来我们考虑如何在模拟的 M1 机型上启动真正的 MacOS 。

• 机器上电，由 Boot ROM 验证并加载位于 Flash 中的 LLB（Low Level Bootloader）
• LLB 设置安全策略、解密/认证并加载位于 preboot volume 中的 iBoot 文件
• iBoot 根据 DTB 对 M1 固件和设备做早期的初始化，验证并加载 KernelCache（KernelCache 是 MacOS 启动镜像，类似于 linux 的 Image.gz），更新并加载 DTB
• 进入 MacOS 内核启动流程。

其中无论是 LLB 还是 iBoot 都是闭源的，这为我们完整的模拟 M1 启动带来了难处。为了能成功的在 QEMU / KVM 虚拟化场景下启动 M1，我们对 MacOS 的启动过程做了简化，割舍掉 LLB 和 iBoot 阶段，直接由 QEMU 来完成早期设备的初始化（如 CPU 状态等）、KernelCache 文件的解析与加载、DTB 的更新与加载等。

• KernelCache：包含了 XNU 内核和 kext 内核扩展，是 MacOS 的内核镜像
• Ramdisk：HFS 格式的 rootfs，可作为 MacOS 的启动盘使用，非必需（当使用 virtio-blk 盘作为启动盘时，可取消 Ramdisk 的使用）
• DTB：M1 的设备树，MacOS 内核需要通过 DTB 来获取到 M1 的硬件信息，QEMU 模拟的 M1 设备信息（如中断路由和设备地址信息等）要和 DTB 中维护的信息一致
• xnu_arm64_boot_args：Macos 内核的启动参数

随后 QEMU 将 Primary VCPU 的 pc 寄存器设置为 KernelCache 中的 start 函数地址，开始VCPU 的运行。

MacOS 在 QEMU / KVM 虚拟化场景下整体的启动流程如图，大致分如下四个阶段：

1. QEMU 阶段

该阶段在 QEMU 中实现，主要是为 MacOS 的运行做准备，具体包括 VCPU 线程的创建，各设备状态的初始化，System Memory 的加载映射（如KernelCache、 Ramdisk、DTB)，bootargs 的创建和 DTB 数据的更新等，随后将 VCPU0 的 pc 寄存器指向 MacOS XNU 内核的_start 函数，VCPU0 开始执行。

2. 早期初始化阶段

3. Kernel 阶段

在 arm_init 和 kernel_bootstrap 中， 主要是第一个内核线程启动前的准备工作，如进行 KernelCache 解析、DTB 转化，console 设置，per cpu data 设置和 process 初始化、系统内存的初始化以及内核各个子系统的启动。

kernel_bootstrap_thread/bsd 中，主要是启动其他的系统维护线程构筑 MacOS 的运行时环境，如初始化 I/O Kit 框架，初始化 BSD 子系统。其间还会根据 DTB 的配置来设置 SMP，唤醒其他 VCPU；其中， I/O Kit 是MacOS XNU 内核为设备驱动程序提供的完整的运行时环境，用户可以基于 I/O Kit 提供的面向对象能力来快速高效地编写自己的驱动程序。

在 bsdinit 中,初始化 BSD 核心子系统, 挂载 rootfs 并启动 /sbin/launched。

4. 用户态服务和进程

/sbin/launched 进程的 pid 为1，为第一个用户态进程，它根据预定的安排或者实际的需要加载位于 /System/Library/LaunchAgents 和 /System/Library/LaunchDeamons 下的其他应用程序或作业，包括守护程序如 atd、crond、inetd 等，以及代理程序如 GUI shell、 Terminal shell 等。

至此 MacOS M1 基本启动已经完成。

其中，M1 Guest OS 在 XNU 内核的基础上会加载多个 Kext 以实现完整的 MacOS 功能；既支持 APFS 格式的根文件系统，也支持 HFS 格式的 Ramdisk 根文件系统；dyld 类似于 linux 上的 ld，负责加载和链接应用程序，dyld_shared_cache 提供了系统中各进程共享的基础库缓存，有效地降低了各进程通用库的内存占用率。

目前我们已经完成了 QEMU / KVM 虚拟化场景下 MacOS M1 的基本启动，后续需要有更多的优化从功能完备性、性能以及兼容性的角度来展开。

5.1 更完善的MacOS 运行时环境

目前我们的方案在 QEMU 层实现了 M1 基本设备的模拟、在 KVM 层实现了硬件加速功能、在 MacOS 中实现了部分系统服务的启动，然而整个方案与一台真正的 MacOS 还有一定的距离，如默认启动的数百个系统服务、友好的 GUI 界面、更完备的设备支持以及更好的用户支持度等等，后续将持续优化。

5.2 兼容性

在整个虚拟化方案中为了实现 MacOS 的启动，我们对 KernelCache 里的 XNU 内核和 Kext 部分进行了热 Patch。后续需要实现合理的热 patch 的工具来完成不同的 MacOS 版本热 Patch 的高效定制。

5.3 性能问题

模拟 M1 机型时，像 PMGR 和 AIC 这样的设备，我们目前是直接在 QEMU 里进行模拟的，这会使得虚拟机对 PMGR 和 AIC 的操作，都需要退回到 QEMU 中来进行具体行为的模拟，后续可考虑将这些组件集成到 KVM 中，减少用户态和内核的切换，减少虚拟化开销，提高 VM 的性能。