Slide 1

Slide 1 text

⾃作ハイパーバイザーを 作ってNuttXを動かした話 @HMatsubayashi @HidenoriMatsubayashi

Slide 2

Slide 2 text

はじめに 本資料は、 • Arm64 にフォーカスした(他のアーキテクチャには触れない)内容 • 細かい話より、Hypervisorの仕組みが⼤まかに理解出来ることが⽬的 • 仕事とは関係がない個⼈的なアクティビティ です

Slide 3

Slide 3 text

なぜHypervisorなのか?なぜ⾃作なのか? • 仮想化技術の基礎を学べる • Hypervisor ≒ ⼩さなOS + 仮想化 • OSに必要な基本的な機能が⼀通り必要 • タスク (vCPU) スケジューラ、MMU/メモリ管理、マルチコアなど • ソースコード規模が⼩さい • 実⽤的なHypervisorでも数〜10万⾏程度のソースコード規模 • ⾃作した eVisor は約6500⾏ • ゲストOSは既存のもの(Linux, NuttXなど)がそのまま動く • ⾃作OSだとユーザランドをそれなりに作る必要があり(動作確認などのため)、時間がかかる • ⾃作する⽬的 • 作り⽅と仕組みを学ぶため • 徐々に動くようになっていく過程が楽しいから

Slide 4

Slide 4 text

⽬次 • Hypervisorとは? • Arm64 Hypervisor の概要と仕組み • eVisor (⾃作Hypervisor) を作ってみた • 今後

Slide 5

Slide 5 text

Hypervisorとは? • 1台の物理マシン上で複数の仮想マシン (VM) を動かす環境を提供 • そのVM上でゲストOSは動作 • ゲストOSは隔離された環境で動作 • 他のゲストOSには影響を与えない • H/Wリソースは必要に応じてゲストOSに割り当て管理 • 必要に応じて仮想化 • H/Wの仮想化⽀援機構を出来るだけ利⽤ • 結局はエミュレータみたいなものだが、Hypervisorは実際のCPU (H/W) を利⽤してVMを動かす H/W Hypervisor VM VM VM OS OS OS

Slide 6

Slide 6 text

Type1 と Typ2 の2種類のHypervisor • Type1 (Baremetal) • H/W上で直接動作し、VMを作成するタイプ • 例: • Linux KVM (ハードウェアの仮想化はできず、vCPUのみのはず) • JAILHOUSE • Type2 (Host) • H/W上で動作するゲストOSの上で動作し、VMを作成して動かすタイプ • 実装/Hypervisorにもよるが、エミュレータに近いイメージ • 例: • VMware Player • QEMU (ただし、KVMを利⽤可能なので厳密にはType2ではない)

Slide 7

Slide 7 text

ここから先はType1 Hypervisor前提の内容 (Type2のことは⼀切触れない)

Slide 8

Slide 8 text

Hypervisor (仮想化) の実現⽅法 • 基本的な仕組み • 前提としてCPUの仮想化⽀援が必須 • vCPU (VM) の特定の命令やメモリアクセスなどをHypervisorがトラップ • Hypervisorに割り込みが⼊る • 何の操作が⾏われたか確認して適切な処理を⾏い、再度VMを動かす • 必要に応じてH/Wを仮想化する • 同⼀のH/Wが複数VMで利⽤される場合 • なお、メモリマップの設定次第では直接H/Wアクセスの許可も可能 • 仮想化⽀援機構 • CPUコア • Hypervisor専⽤の動作モードを持っている • 特定の動作/メモリアクセス/割り込みをトラップする仕組みを提供 • H/W • これはSoCによるが、あるものとないものがある

Slide 9

Slide 9 text

Arm64の仮想化⽀援機構 ‒ CPUコア • ARMv7-Aから仮想化をサポート • EL (Exception Level) という CPUの動作モード(特権モード)がある • ELの数値が⼤きいほど、出来ること(特定レジスタへのアクセスなど)が増える • ⾃分よりもレベルが低いELの動作をトラップ出来る • 例えば、メモリアクセスフォルト、特定のCPUレジスタへのアクセスなどのセンシティブ 命令など • EL0: ユーザアプリ • EL1: OS • EL2: Hypervisor • EL1/0の動作をEL2でトラップし、必要な処理を⾏った後、またEL1に処理を戻す • EL3: Firmware (セキュアモニタ)

Slide 10

Slide 10 text

Arm64の仮想化⽀援機構 ‒ CPUコア • CPUタイマー (Arm Generic Timer) • 複数VMが動く場合、⾃分以外のVMが動いている間に経過したリアル時間 (オフセット)を隠蔽する必要あり ⇨ 物理的なタイマーに対してオフセットを付与できる仮想タイマー機能あり • 詳細: https://zenn.dev/hidenori3/articles/413d8ef0a67463

Slide 11

Slide 11 text

Arm64の仮想化⽀援機構 ‒ システムコール • HVC 命令 • EL1からEL2に処理を戻す時に利⽤ • Hypervisor⽤のシステムコールとして利⽤ • APIを実装していけば KVM みたいなことが可能

Slide 12

Slide 12 text

Arm64の仮想化⽀援機構 ‒ メモリの仮想化 • MMU Stage2 • Hypervisorが利⽤する通常のMMU (Stage1) の仮想アドレスに対し て、さらにゲストOS毎に⾃由にメモリをマッピング可能 • 中間アドレス, IPAなどと呼ぶ • ゲストOS毎にメモリ空間を隔離する必要あるため • デバイスI/Oの割り当て • 必要に応じて仮想デバイスの空間に割り当て • もし仮想化の必要がなければ、実アドレスに割り当ても可能 • メモリの割り当て • eVisorはオンデマンドページングで対応 • 事前に利⽤する領域が確定している、OSの起動⾼速化などが不要 であれば、事前に割り当ても可能 • 詳細 • https://zenn.dev/hidenori3/articles/91494881d318a5

Slide 13

Slide 13 text

Arm64の仮想化⽀援機構 ‒ 割り込みコントローラ • ARM Generic Interrupt Controller (GIC) は v2.0か ら仮想化をサポート • 本資料ではGICの仕組みを説明 • なお、GIC以外の割り込みコントローラの仮想化はH/W 次第 • 基本的な仕組みは以下 1. 物理的なIRQをHypervisor (EL2) が⼀旦受ける 2. IRQ要因を⾒て、それがゲストOS (EL1) 向けのもの であれば、EL2からEL1に vIRQ を発⾏ • IRQ番号はHypervisorが⾃由に設定可能 3. EL1は通常のIRQとして認識して動く • 詳細 • https://zenn.dev/hidenori3/articles/b5bad28b262db4

Slide 14

Slide 14 text

GICの割り込み仮想化はソフトウェア対応が必要 • Hypervisor側で⼀部エミュレーションが必要で少し⾯倒 GICD (Distributor) GICC (CPU interface) GICH (Hypervisor) GICV (vCPU interface) GICD エミュレーション GICD (Distributor) GICC (CPU interface) 実際のH/W Hypervisor vCPU MMU Stage2でGICC領域 をGICVにマッピング GICDはvCPU毎にエミュ レーションが必要 GICD: IRQ有効設定などのレジスタ GICC: IRQ要因などのレジスタ

Slide 15

Slide 15 text

ARM64の仮想化⽀援機構 ‒ その他H/W • H/Wを複数のゲストOSで利⽤する場合、Hypervisor側で • H/Wをフルエミュレート • 必要なH/Wレジスタのスナップショット(バックアップ)、VM切り 替え時にスナップショットも⼀緒にコンテキストスイッチ などの対応が必要(H/W側で仮想化⽀援機構がない限り)

Slide 16

Slide 16 text

ここまで分かれば、 ⾃作Hypervisorを作ることが出来る!

Slide 17

Slide 17 text

eVisor (⾃作Hypervisor) 概要 • 特徴 • マルチvCPUサポート • Hypervisor Shell • シリアルコンソール仮想化 • Hypervisor デバッグ&シェル⽤ • ゲストOSのシリアル⽤ • GIC v2サポート • ファイルシステム • FAT32 • ドライバ • GPIO • MailBox • MMC (SDカード) • UART (PL011) • H/Wサポート • QEMU • Raspberry Pi 4 (BMC2711) • なお、未実装機能多数あり • マルチコアサポートなど • ソースコード • https://github.com/HidenoriMatsubayashi/evisor H/W Driver (GPIO, MMC, UART, Timer, etc) FileSystem Memory Management Scheduler Virtual Machine vCPU vCPU vCPU EL2 EL1

Slide 18

Slide 18 text

NuttX on eVisor on Rasberry Pi4 • NuttX は RPI4 未サポート • 仕⽅がないので、NuttXは サポート済みのQEMU向 けにビルド • MMU Stage2で辻褄が合 うようにメモリとデバイ スI/Oを割り当て • UARTはNuttXとeVisorの 両⽅が同時に使えるよう にeVisorでエミュレー ション

Slide 19

Slide 19 text

振り返り 1. Raspberry Pi4で動くように作り始める 2. MMUを有効にすると正常に動かずハマる@Raspberry Pi4 3. 途⽅に暮れ、デバッグのためにQEMUサポートを追加する 4. QEMUサポート追加し、作業効率が激上げする 5. NuttXをゲストOSに利⽤するためビルドを開始 • 当時はQEMU for ARM64のみサポート 6. NuttXのソースコードを⾒ていると改善ポイントがいくつかあったので、数件のPR (Pull request) を作って送るなどする 7. QEMUでは動くが、Raspberry Pi4 だと動かないバグにハマる • このパターンの多くは、キャッシュ周りのバグ(フラッシュ忘れなど) 8. NuttXがブート成功 9. eVisorからNuttX側への仮想割り込みが正常に通知されないバグにハマる 10. NuttXのシェル操作やそこからプログラム実⾏などが出来るようになる 11. ゼルダの伝説ティアーズオブザキングダム (Switch) 以外何も⼿が付かなくなる(現在)

Slide 20

Slide 20 text

今後 • ゲストOSでLinuxを動かす • 未実装機能の実装 • マルチVM (ゲストOS) のサポート • ⼤体は実装済みだが、⼀部のコンテキストスイッチが未実装 • マルチCPUコアのサポート • KVMみたいなAPIの追加 など • ゼロから作る⾃作Hypervisor的な記事(本)を書く

Slide 21

Slide 21 text

EOF