近年の車載システムでは ECU 統合が進み、safety critical な制御 OS と Linux/Android のようなリッチ OSを同一 SoC 上で安全に共存させる要求が増えています。これに対する代表的な解決策が仮想化であり、Hypervisor により CPU、メモリ、I/O を分離して複数の OS を同時に動作させます。
このアプローチに関連して、R-Car H3評価ボード上において、eSOLが提供する「eMCOS Hypervisor」でAAOS（Android Automotive OS）を動かしてみました。『理屈の上では動くはず』とは思っていたのですが、これまでちゃんと手を動かして試したことがなかったので、その結果を「全体構成」「設定のポイント」に絞ってまとめます。最後に、実際に動いているデモ動画も紹介します。
1. やってみたこと
実際にやってみて、以下まで確認できました。
- AAOS が起動し、画面が出力される
- AAOS 上のアイコン操作により画面が遷移できる
- 音が出力できる
- ネットワーク接続できる
- 体感として スムーズに動作する
2. 検証環境
| 項目 | 内容 |
| SoC / Board | ルネサスエレクトロニクス社 R-Car H3 評価ボード |
| Hypervisor | eMCOS Hypervisor |
| Guest OS | AAOS（Android Automotive OS） (Android v10_2.0) R-Car/Boards/Kingfisher/Android/Android 10 - eLinux.org |
| 仮想 CPU / RAM | 8 仮想CPU, 1.5GB RAM |
| 仮想 CPU スレッドの配置 | 優先度は Hypervisor のシステム系プロセスより低かつ、別コアへ配置） |
| パススルーデバイス | GPU/ディスプレイ/サウンド/USB |
| Virtio デバイス | virtio-console（シリアル）/ virtio-net（Ethernet）/ virtio-blk（Storage: SD card） |
| 動作確認 | AAOS 起動〜画面出力、画面遷移、音出力 |
3. 全体構成（ざっくり図）
今回やってみた基本方針はシンプルで、性能や既存資産を活かしたい I/O はパススルー、共有や抽象化が必要な I/O は仮想化（virtio）という切り分けです。こんにちの車載システムではこの混在構成が一般的です。
4. Hypervisor によるメモリー分離
AAOS のようなリッチ OS を safety-critical なシステムに載せるときに重要になるのは、Guest OS が自分の物理メモリーと思ってアクセスしていても、最終的にどの物理メモリーへ到達するかを Hypervisor が制御できる点です。
eMCOS Hypervisor では Armv8-A の Stage-2 translation を用い、Guest OS の物理アドレス相当となる中間物理アドレスを Guest OS に見せます。中間物理アドレスと実際の物理アドレスのマッピングは Stage-2 translation で定義します。これにより Guest は実際の物理アドレスの配置を意識せず動作します。
また、Guest OS が想定外の物理アドレスへアクセスした場合は、 MMU 例外が発生し、Hypervisor に制御が戻ります。そのため、そのような想定外のアクセスがあっても、他の Guest や eMCOS Hypervisor 自身のメモリーへ直接影響しません。
さらに Stage-2 translation は分離機構としてだけでなく、設定により Guest 間、Guest - Host 間の 共有メモリー を設定する仕組みとしても使えます。
5. 仮想 CPU (vCPU) スレッドの構成
eMCOS Hypervisor のスケジューリング設計の特徴は、Hypervisor 自身に専用の VM スケジューラを持たず、VM の実行単位である vCPU スレッドを eSOLのリアルタイムOS「eMCOS ® POSIX」 上の通常スレッドとして扱う点です。vCPU は eMCOS POSIX の準優先度スレッドスケジューリングにしたがって実行されます。
この構成だと、vCPU スレッドの優先度設計がシステム全体の挙動を決める重要な要素になります。Guest OS に割り当てた vCPU スレッドの優先度を調整することで、リアルタイム性の高い処理を優先的に回したり、逆にバックグラウンド的に実行できたりします。safety critical な処理を eMCOS アプリケーションとして動かし、Guest OS より高い優先度を与える構成も取りやすくなります。
今回の vCPU スレッドの設定:
- vCPU 数：8
- 優先度：Hypervisor のシステム系プロセスより低 (バックグラウンド的な処理として扱
- コア配置：Hypervisor のシステム系プロセスと別コアに配置
以下は eMCOS Hypervisor の構成図です。POSIX Real-time Applications は eMCOS POSIX 上の Native POSIX アプリケーションを指します。 Native POSIX アプリケーションも vCPU もeMCOS POSIX のスレッドとして統一的にスケジューリングされます。
6. デバイスの構成: パススルーと virtio の切り分け
6.1 パススルー（GPU/Display/Sound/USB）
パススルーは、Hypervisor が原則としてデバイスアクセスに介在せず、Guest OS が実デバイスをそのまま操作する方式です。既存の Linux/Android 向けドライバ資産をそのまま活かしやすく、レイテンシ/スループット重視のデバイスに向きます。一方で、デバイスの Guest 間共有ができず割り当ての自由度が下がる点がトレードオフです。
今回パススルーしたもの：
- GPU
- ディスプレイ
- サウンド
- USB
6.2 Virtio（virtio-console/virtio-net/virtio-blk）
virtio は仮想化環境で仮想デバイスを扱うための標準インターフェース仕様で、OASIS で仕様が定義されています。特定 Hypervisor 依存になりにくいのがポイントです。
virtio は仮想デバイスであることを前提に、データ転送は共有メモリー、制御/通知はイベントとして扱うことでオーバーヘッドを抑える仕様になっています。 また、標準インターフェースを採用することで、Linux/Android が持つ既存ドライバ資産を活用しやすくなり、ソフトウェア再利用性も高めることができます。
今回 virtio を使ったもの：
- virtio-console（シリアル）
- virtio-net（Ethernet）
- virtio-blk（ストレージ: SD card）
6.3 DTB
上記のデバイス設定は AAOS の Device Tree で調整できます。今回のトライアルでは、AAOS のイメージを eMCOS Hypervisor 向けにビルドしなおす必要はありませんでした。パススルーデバイスを初期化する場合、Pin Multiplexer、Clock などホストやほかのゲスト OS と共有するペリフェラルの設定が必要です。eMCOS Hypervisor では仮想BSPという仕組みを入れることで実現できました。仮想 BSP により、そのような共有ペリフェラルのうちゲストOSが必要とする部分だけを設定可能にできます。
7. 動作の様子
8. まとめ
今回、R-Car H3 評価ボード上の eMCOS Hypervisor で AAOS を実際に起動させ、UI を動作（画面遷移・音出力）させるところまでやってみました。
本記事のまとめとして、今回のトライアルでの要点は以下になります。
- eMCOS Hypervisor では vCPU スレッドを eMCOS のスレッドとして扱うため、優先度設計とコア配置の設定がポイントになる
- デバイスは、性能・既存資産を活かしたいものをパススルー、共有・抽象化したいものを virtio とする切り分けが現実的
本記事でご紹介した通り、eMCOS Hypervisorは仮想化技術によって求められる安全性が異なるOSとの共存を実現し、SDV時代の車載ソフトウェア開発で必要性が高まるECU統合を強力に支援します。
OSの共存や仮想化技術・Hypervisorの活用で課題をお持ちの方は、ぜひお気軽にご相談ください。
エンジニアリング本部 OS開発部 坂本 裕和
