探索Mac mini M1的QEMU/KVM虛擬化實現(xiàn)

背景

目前業(yè)界云平臺一般會提供 Windows 虛擬機和 Linux 虛擬機，用戶可以在這些虛擬機上部署符合 Windows生態(tài)和 Linux 生態(tài)的服務和應用。MacOS 作為 Apple 生態(tài)的基本操作系統(tǒng)，MacOS 虛擬化的實現(xiàn)將會為使用 Apple 生態(tài)的用戶帶來很大的便利，如直接在 MacOS 的虛擬機上進行測試、構(gòu)建iOS 應用，甚至使用 MacOS 虛擬機作為辦公環(huán)境等。

目前社區(qū)對于 Intel x86 Mac mini 平臺的 MacOS虛擬化方案已經(jīng)比較成熟，隨著 2020年 Apple 推出自研的 ARM64 M1芯片，Mac mini 增加了對 ARM64 平臺的支持，后續(xù) Apple 將逐漸從 Intel x86 芯片轉(zhuǎn)向自研的 ARM64 芯片。相對于 Intel x86 平臺，社區(qū)對 ARM64 平臺的 MacOS 虛擬化方案還在探索和起步階段，于是字節(jié)跳動 STE 團隊和 App Infra 團隊率先進行了深入的研究，本文將與大家分享針對采用 ARM64 M1 芯片的 Mac mini M1 機型虛擬化方案的探索和實現(xiàn)。

方案介紹

什么是 Mac mimi 虛擬化

Mac mini 虛擬化是指在一臺 Mac mini 物理機上模擬出多個互相隔離的 Mac mini 虛擬機，使得每個虛擬機用戶都認為自己在一臺真正的物理機上以獨占的方式運行。

整個方案中，我們采用了云平臺常見的 Linux + KVM(Kernel-based Virtual Machine）+ QEMU(Quick EMUlator) 這樣全開源的虛擬化軟件棧，以方便把控和實現(xiàn)對 Mac mini M1 機型（包括 CPU / MEM /片上設(shè)備/外設(shè)等）的全方位模擬。在 Mac mini M1 的虛擬化實現(xiàn)中，我們基于 QEMU 既有的機型框架實現(xiàn)了對 Mac mini M1 的軟件模擬（TCG, Tiny Code Generator）支持，又通過 KVM 為Mac mini M1 提供了ARM64平臺硬件虛擬化能力的支持。

Linux

Asahilinux 對 M1 機型上的硬件設(shè)備做了足夠多的逆向工程分析，并根據(jù)推出來的硬件邏輯來嘗試實現(xiàn)linux下的各設(shè)備驅(qū)動，目前已實現(xiàn)了對 M1 機型的基本支持，其中對 M1 GPU的支持也在不斷完善中。Asahilinux這部分工作也在不斷的合入Linux upstream。

我們采用Asahilinux作為運行在M1裸機上的操作系統(tǒng)。依賴Asahilinux，我們可以獲得M1 的 linux 運行時物理機環(huán)境，并以此為基礎(chǔ)逐步構(gòu)建和實現(xiàn)M1虛擬化所需的虛擬化軟件棧。

QEMU

QEMU 作為機型/系統(tǒng)模擬的常用軟件，構(gòu)造了機型模擬的基本框架，并在此基礎(chǔ)上提供了不同平臺上很多具體機型的模擬實現(xiàn)，比如 x86 平臺的 piix 和 Q35 機型，ARM 的 virt 和 raspi2 等。在 M1 機型的虛擬化中我們需要基于 ARM64 通用機型，構(gòu)造一個新的 M1 機型，并集成到 QEMU 提供的機型模擬框架中。

QEMU 提供的基本模擬方式是純軟件的，即對于每一條虛擬機內(nèi)部執(zhí)行的指令都需要退出到 QEMU 的上下文來翻譯執(zhí)行(TCG)，該方式性能很低。KVM 可以幫助我們解決 QEMU 純軟件模擬帶來的低性能問題。

KVM

KVM 作為 Linux 下支持虛擬化的內(nèi)核模塊，將虛擬化場景下的硬件加速功能通過 ioctl 的方式導出給QEMU使用。在 KVM 的支持下，虛擬機內(nèi)部的常用指令將不再需要退出到QEMU來模擬執(zhí)行，而是在虛擬機的 CPU 上下文中直接執(zhí)行，只有個別特權(quán)指令才需要退出到物理機上，由物理機來具體執(zhí)行。對于虛擬機的內(nèi)存訪問，也不再需要 QEMU 進行頁表翻譯，而是直接依賴硬件實現(xiàn)的兩級頁表翻譯機制（虛擬機內(nèi)部頁表實現(xiàn) Guest Virtual Address向Guest Physical Address的轉(zhuǎn)化，使用stage2 page table 實現(xiàn) Guest Physical Address向Host Physical Address的轉(zhuǎn)化），從而實現(xiàn)內(nèi)存的快速訪問。

M1機型的模擬

了解了基本的虛擬化軟件棧后，我們開始考慮如何模擬一臺真正的 Mac mini M1。那么，模擬 M1 機型包括模擬哪些內(nèi)容呢？

M1 VCPU

QEMU 中使用線程來模擬 VCPU，即每一個 VCPU 對應一個單獨的 QEMU 線程；使用必要的數(shù)據(jù)結(jié)構(gòu)記錄 VCPU 相關(guān)的信息，如寄存器/運行狀態(tài)等。區(qū)別于其他機型的 VCPU，M1 需要增加的特有支持如下： 1）多個 M1 特有寄存器和對應的讀寫邏輯； 2）對 Apple PMGR（電源管理模塊）的模擬。M1 通過 PMGR 來實現(xiàn)多核（SMP，symmetric multiprocessing）的喚醒和管理；

3）Cluster 內(nèi)和 Cluster 間的 Fastipi 通信機制；

M1 內(nèi)存布局

M1 的內(nèi)存布局，是指將VM的整個地址空間按照設(shè)備和用途進行合理的劃分，如 Flash device、CPU 相關(guān)的固件、中斷控制器、Spec 設(shè)備地址、MMIO 和 PCI 地址范圍以及虛擬內(nèi)存等。在 QEMU 層設(shè)置 M1 機型的內(nèi)存布局需要注意以下幾個問題： 1）注意 CPU 地址域和設(shè)備地址域的關(guān)系； 2）System Memory 范圍不能跟 DTB（Device Tree Blob） 中各設(shè)備的物理地址空間沖突； 3）需要連續(xù)的足夠大的地址范圍來映射 System Memory；

System Memory 作為虛擬機的主存，在啟動初期會被用來存放內(nèi)核鏡像、設(shè)備樹以及Ramdisk等，這些內(nèi)容的加載地址也需要額外配置，注意不能存在交叉，以避免內(nèi)存中內(nèi)容互相覆蓋。

M1 設(shè)備模擬

區(qū)別于 M1 物理機，M1 虛擬機的存儲和網(wǎng)絡(luò)主要采用虛擬化場景下常見的 virtio-pci 設(shè)備，如 virtio-blk / virtio-net 設(shè)備等。我們需要在模擬的 M1 機型上插上 PCIE 的線，其下接各種 PCI / PCIE 設(shè)備。另外，為了讓設(shè)備的中斷能夠順利分配、觸發(fā)并遞送到目的 VCPU 中，還需要模擬 M1 的中斷控制器 AIC。

AIC 是 M1 Apple Interrupt Controller 的簡稱， 主要負責中斷掩碼/中斷狀態(tài)設(shè)置、接受/遞送中斷等。對 AIC 的模擬主要是對上述的功能的模擬，可以通過 Asahilinux 的 AIC 驅(qū)動部分的代碼邏輯來推斷出 AIC 具體地址空間的含義，從而實現(xiàn) AIC 的模擬。對 AIC 的模擬中我們使用了 MMIO（Memory-Mapped IO） 空間來實現(xiàn)對 AIC 內(nèi)部相關(guān)硬件地址的訪問邏輯。

對 M1 新插上的 PCIE 總線的模擬基于 QEMU 提供的通用 PCIE 線——gpex-pcihost 來實現(xiàn)，在通用的 gpex-pcihost 模型的基礎(chǔ)上，我們需要根據(jù) M1 的 DTB 文件來制定 M1 PCIE 總線配置空間和bar空間，以及其下 PCI 設(shè)備的 PCI 配置空間和 Bar 地址空間范圍。

整體的中斷設(shè)計如下：

將模擬的 M1 PCIE （gpex-pcihost ）總線的 4 個 gpio_out pin 依次連接到 AIC 的 gpio-in pin 上去。gpex-pcihost 通過該連線傳遞中斷給AIC；

AIC 有 cpu_num 個 gpio_out pin ，這些引腳分別連接到各個 CPU 上，AIC 通過該連線遞送中斷給 CPU。

至此，我們已經(jīng)在 QEMU 層面實現(xiàn)了對 M1 的 CPU、PMGR、AIC、PCIE 總線等設(shè)備的基本模擬，可以通過 QEMU 命令在 PCIE 線上插上所需的 PCI 設(shè)備，如 virtio-blk、virtio-net 等，來嘗試啟動 MacOS 虛擬機了。

虛擬化下的MacOS和啟動

既然已經(jīng)完成了對 M1 虛擬機所需要的基本組件的模擬，接下來我們考慮如何在模擬的 M1 機型上啟動真正的 MacOS 。

預啟動階段

MacOS 的啟動流程是怎樣的呢？MacOS 在 M1 物理機上的啟動流程如下（更多詳見M1 啟動過程：https://eclecticlight.co/2022/01/05/booting-an-m1-mac-from-hardware-to-kexts-2-llb-and-iboot/）

機器上電，由 Boot ROM 驗證并加載位于 Flash 中的 LLB（Low Level Bootloader）

LLB 設(shè)置安全策略、解密/認證并加載位于 preboot volume 中的 iBoot 文件

iBoot 根據(jù) DTB 對 M1 固件和設(shè)備做早期的初始化，驗證并加載 KernelCache（KernelCache 是 MacOS 啟動鏡像，類似于 linux 的 Image.gz），更新并加載 DTB

進入 MacOS 內(nèi)核啟動流程。

其中無論是 LLB 還是 iBoot 都是閉源的，這為我們完整的模擬 M1 啟動帶來了難處。為了能成功的在 QEMU / KVM 虛擬化場景下啟動 M1，我們對 MacOS 的啟動過程做了簡化，割舍掉 LLB 和 iBoot 階段，直接由 QEMU 來完成早期設(shè)備的初始化（如 CPU 狀態(tài)等）、KernelCache 文件的解析與加載、DTB 的更新與加載等。

在 QEMU 完成早期初始化和預加載后，虛擬機啟動時刻的 System Memory 地址空間布局狀態(tài)如下：

其中，各文件的含義如下：

KernelCache：包含了 XNU 內(nèi)核和 kext 內(nèi)核擴展，是 MacOS 的內(nèi)核鏡像

Ramdisk：HFS 格式的 rootfs，可作為 MacOS 的啟動盤使用，非必需（當使用 virtio-blk 盤作為啟動盤時，可取消 Ramdisk 的使用）

DTB：M1 的設(shè)備樹，MacOS 內(nèi)核需要通過 DTB 來獲取到 M1 的硬件信息，QEMU 模擬的 M1 設(shè)備信息（如中斷路由和設(shè)備地址信息等）要和 DTB 中維護的信息一致

xnu_arm64_boot_args：Macos 內(nèi)核的啟動參數(shù)

隨后 QEMU 將 Primary VCPU 的 pc 寄存器設(shè)置為 KernelCache 中的 start 函數(shù)地址，開始VCPU 的運行。

啟動流程

MacOS 在 QEMU / KVM 虛擬化場景下整體的啟動流程如圖，大致分如下四個階段：

1. QEMU 階段

該階段在 QEMU 中實現(xiàn)，主要是為 MacOS 的運行做準備，具體包括 VCPU 線程的創(chuàng)建，各設(shè)備狀態(tài)的初始化，System Memory 的加載映射（如KernelCache、 Ramdisk、DTB)，bootargs 的創(chuàng)建和 DTB 數(shù)據(jù)的更新等，隨后將 VCPU0 的 pc 寄存器指向 MacOS XNU 內(nèi)核的_start 函數(shù)，VCPU0 開始執(zhí)行。

2. 早期初始化階段

在 MacOS 啟動早期的匯編代碼階段，_start 函數(shù)設(shè)置了內(nèi)核啟動早期的中斷/異常向量表和頁表等，并對內(nèi)核參數(shù)進行解析，配置 MMU 和 vbar 等。

3. Kernel 階段

在 arm_init 和 kernel_bootstrap 中， 主要是第一個內(nèi)核線程啟動前的準備工作，如進行 KernelCache 解析、DTB 轉(zhuǎn)化，console 設(shè)置，per cpu data 設(shè)置和 process 初始化、系統(tǒng)內(nèi)存的初始化以及內(nèi)核各個子系統(tǒng)的啟動。

kernel_bootstrap_thread/bsd 中，主要是啟動其他的系統(tǒng)維護線程構(gòu)筑 MacOS 的運行時環(huán)境，如初始化 I/O Kit 框架，初始化 BSD 子系統(tǒng)。其間還會根據(jù) DTB 的配置來設(shè)置 SMP，喚醒其他 VCPU；其中， I/O Kit 是MacOS XNU 內(nèi)核為設(shè)備驅(qū)動程序提供的完整的運行時環(huán)境，用戶可以基于 I/O Kit 提供的面向?qū)ο竽芰砜焖俑咝У鼐帉懽约旱尿?qū)動程序。

在 bsdinit 中,初始化 BSD 核心子系統(tǒng), 掛載 rootfs 并啟動 /sbin/launched。

4. 用戶態(tài)服務和進程

/sbin/launched 進程的 pid 為1，為第一個用戶態(tài)進程，它根據(jù)預定的安排或者實際的需要加載位于 /System/Library/LaunchAgents 和 /System/Library/LaunchDeamons 下的其他應用程序或作業(yè)，包括守護程序如 atd、crond、inetd 等，以及代理程序如 GUI shell、 Terminal shell 等。

至此 MacOS M1 基本啟動已經(jīng)完成。

虛擬化下完整的MacOS 軟件棧

QEMU/KVM 虛擬化場景下的 MacOS 整體架構(gòu)圖如下，從下到上依次是M1物理機、支持 M1 各類型設(shè)備的 Asahilinux 內(nèi)核、提供硬件加速功能的內(nèi)核模塊 KVM、實現(xiàn) M1 機型模擬的用戶態(tài) QEMU，運行在 QEMU 上的 M1 Guest OS。

其中，M1 Guest OS 在 XNU 內(nèi)核的基礎(chǔ)上會加載多個 Kext 以實現(xiàn)完整的 MacOS 功能；既支持 APFS 格式的根文件系統(tǒng)，也支持 HFS 格式的 Ramdisk 根文件系統(tǒng)；dyld 類似于 linux 上的 ld，負責加載和鏈接應用程序，dyld_shared_cache 提供了系統(tǒng)中各進程共享的基礎(chǔ)庫緩存，有效地降低了各進程通用庫的內(nèi)存占用率。

后續(xù)規(guī)劃和展望

目前我們已經(jīng)完成了 QEMU / KVM 虛擬化場景下 MacOS M1 的基本啟動，后續(xù)需要有更多的優(yōu)化從功能完備性、性能以及兼容性的角度來展開。

5.1 更完善的MacOS 運行時環(huán)境

目前我們的方案在 QEMU 層實現(xiàn)了 M1 基本設(shè)備的模擬、在 KVM 層實現(xiàn)了硬件加速功能、在 MacOS 中實現(xiàn)了部分系統(tǒng)服務的啟動，然而整個方案與一臺真正的 MacOS 還有一定的距離，如默認啟動的數(shù)百個系統(tǒng)服務、友好的 GUI 界面、更完備的設(shè)備支持以及更好的用戶支持度等等，后續(xù)將持續(xù)優(yōu)化。

5.2 兼容性

在整個虛擬化方案中為了實現(xiàn) MacOS 的啟動，我們對 KernelCache 里的 XNU 內(nèi)核和 Kext 部分進行了熱 Patch。后續(xù)需要實現(xiàn)合理的熱 patch 的工具來完成不同的 MacOS 版本熱 Patch 的高效定制。

5.3 性能問題

模擬 M1 機型時，像 PMGR 和 AIC 這樣的設(shè)備，我們目前是直接在 QEMU 里進行模擬的，這會使得虛擬機對 PMGR 和 AIC 的操作，都需要退回到 QEMU 中來進行具體行為的模擬，后續(xù)可考慮將這些組件集成到 KVM 中，減少用戶態(tài)和內(nèi)核的切換，減少虛擬化開銷，提高 VM 的性能。

審核編輯：湯梓紅