ハイパーバイザ — 特権命令をどう捕まえるか — 仮想化とクラウドの土台

アプリと DB の下に何が積まれているか(左が下、右が上)

物理機リージョン/AZ
ハイパーバイザVM exit で捕まえる今ここ
VMゲストOS
コンテナnamespace / cgroup
プロセスアプリ / DB

第13週の特権境界に、もう1段外側の境界を足します。アプリとカーネルの間だけでなく、カーネルとその下にも境界が引かれます。

まず結論

VMの中のOSは、自分が機械の最上位だと思って特権命令を出します。その命令は素通りせず、ハードウェアが捕まえてハイパーバイザに制御を渡します。

第13週で見たシステムコールは、アプリが自分から境界を越える依頼でした。ハイパーバイザが受け取るものは依頼ではありません。ゲストは頼んでいないのに、実行しようとした瞬間に止められています。

? 読む前に予測

VMの中で動いているLinuxが、CR3(ページテーブルの位置を示すレジスタ)の書き換えのような特権命令を実行したとき、それを最初に受け取るのは誰でしょうか。

当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。

抽象原理

ゲストは「自分が最上位だ」と思っている

前回、1台の機械を分ける理由を見ました。次に出てくる問題は、分けた片方の中で動くOSをどう扱うかです。

VMの中のLinuxは、普通のLinuxです。特別に書き換えられてはいません。だからページテーブルの位置を変え、割り込みを止める命令を、自分が機械の主だと思って出します。それを本当にやらせると、隣のVMの資源まで触れてしまいます。

かといって、すべての命令をソフトウェアで解釈させるのでは遅すぎます。Popek と Goldberg は1974年の論文で、VMMが満たすべき3性質を挙げました(§5)。

There are three properties of interest when any arbitrary program is run while the control program is resident: efficiency, resource control, and equivalence.

そのうち efficiency は次のように定義されています。

The efficiency property. All innocuous instructions are executed by the hardware directly, with no intervention at all on the part of the control program.

無害な命令はハードウェアが直接実行し、制御プログラムは一切介入しない。 つまり「全部を見張る」は最初から選択肢の外で、危ない命令だけを捕まえる必要があります。

定理1は、その条件を述べています。

THEOREM 1. For any conventional third generation computer, a virtual machine monitor may be constructed if the set of sensitive instructions for that computer is a subset of the set of privileged instructions.

危ない命令(sensitive)が、必ず特権命令(privileged)として捕まる側に入っていること。VT-x や AMD-V は、この捕まえる仕組みをハードウェアの側に用意したものです。

具体実物

Intel の文書が使っている言葉

Intel SDM Vol.3(Order 325384-092US, June 2026)は、この仕組みを §26.3 で次のように説明しています。章番号は版で動くので、版を添えて引きます。

Intel SDM Vol.3 §26.3 INTRODUCTION TO VMX OPERATION(325384-092US, June 2026, Vol.3C 26-1)より抜粋コマンド出力

Processor support for virtualization is provided by a form of processor
operation called VMX operation. There are two kinds of VMX operation: VMX
root operation and VMX non-root operation. In general, a VMM will run in
VMX root operation and guest software will run in VMX non-root operation.
Transitions between VMX root operation and VMX non-root operation are
called VMX transitions. There are two kinds of VMX transitions. Transitions
into VMX non-root operation are called VM entries. Transitions from VMX
non-root operation to VMX root operation are called VM exits.

同じ節には、なぜこれで制御が保てるのかも書かれています。

Instead of their ordinary operation, certain instructions (including the new VMCALL instruction) and events cause VM exits to the VMM. Because these VM exits replace ordinary behavior, the functionality of software in VMX non-root operation is limited. It is this limitation that allows the VMM to retain control of processor resources.

ordinary behavior を置き換える という言い方が要点です。ゲストは普通に命令を出したつもりなのに、その普通の振る舞いが差し替えられています。

AMD 側(APM Vol.2 Rev.3.23 §15.6)はこうです。

When an intercept triggers, the processor performs a #VMEXIT (i.e., an exit from the guest to the host context).

同じ仕組みでも Intel は root / non-root、AMD は host / guest mode と呼びます。読むときは出典の側の語に合わせます。

✓ ここまでの確認

「ハイパーバイザはリング0を奪い、ゲストOSをリング1に落として動かす」という説明は、VT-x の説明として妥当ですか。

抽象原理

境界は1本ではなく、積み重なる

第13週で、CPUには特権レベルがあり、アプリはユーザーモードという制限された状態で動くと学びました。ハードウェア支援は、その上に別の軸を足します。

ここで、よくある説明を1つ否定します。「ハイパーバイザがリング0を奪い、ゲストOSをリング1に落とす」。ハードウェア支援の説明としては誤りで、SDM §26.3 の最後の段落は逆のことを書いています。

Because VMX operation places restrictions even on software running with current privilege level (CPL) 0, guest software can run at the privilege level for which it was originally designed.

CPL 0 で動くソフトウェアにも制限がかかるので、ゲストは本来設計された特権レベルのまま動ける。特権レベルを下げる必要がないのです。

ゲストの特権命令が実行されてから戻るまで

ゲストOS(VMX non-root)CR3 書き換えなどの特権命令を実行

依頼ではない。実行しようとした瞬間に止まる

CPU が ordinary behavior を差し替えるVM exit — 制御が VMM 指定の入口へ移る

ハイパーバイザ(VMX root)exit の理由を見て、代わりに処理する

VM entry

ゲストOS の続きへVM entry(VMLAUNCH / VMRESUME)で non-root へ戻す

・用語は Intel SDM Vol.3(325384-092US, June 2026)§26.3・§26.4 のもの
・AMD では guest mode への入りが VMRUN、戻りが #VMEXIT(APM Vol.2 Rev.3.23 §15.5・§15.6)
・ゲスト側に「今 non-root だ」と分かるビットは無い(§26.3)

具体実物

Linux では、捕まえる側は1つのファイルとして見える

Linux では、捕まえる側の入口が普通のデバイスファイルとして現れます。カーネルの KVM API 文書の冒頭はこうです。

The kvm API is centered around different kinds of file descriptors and ioctls that can be issued to these file descriptors. An initial open("/dev/kvm") obtains a handle to the kvm subsystem; this handle can be used to issue system ioctls. A KVM_CREATE_VM ioctl on this handle will create a VM file descriptor which can be used to issue VM ioctls.

open("/dev/kvm") から始まり、KVM_CREATE_VM で VM を、KVM_CREATE_VCPU で仮想CPUを作る。仮想CPUを走らせる ioctl が KVM_RUN です(§4.10「This ioctl is used to run a guest virtual cpu.」)。

ここから逆算できます。/dev/kvm が無い環境には、捕まえる側がいません。 ハードウェア支援があっても、カーネル側の入口が開いていなければ KVM を使うVMは起動しません。

macOS では、対応する仕組みの有無が sysctl に出ます。

実機(macOS 26.5.2、Apple M4)コマンド出力

$ sysctl kern.hv_support
kern.hv_support: 1
$ sysctl kern.hv_vmm_present
kern.hv_vmm_present: 0
$ sysctl -d kern.hv_vmm_present
kern.hv_vmm_present: running on a vmm

読み方に注意が要ります。kern.hv_support: 1 は「この機械で Hypervisor.framework が使える」。kern.hv_vmm_present: 0 は説明文が "running on a vmm" なので「この macOS 自体が VMM の上で動いていない」、つまり物理機だという意味です。0 を「ハイパーバイザが無い」と読むと逆になります。

✓ ここまでの確認

システムコールと VM exit の違いとして正しいものはどれですか。

⇄ 2つを見比べる

具体例 A

システムコール(第13週)

アプリはファイル操作や通信を自分で行えず、カーネルに頼みます。依頼は専用の命令で明示的に出され、ユーザーモードからカーネルモードへ特権レベルが切り替わります。アプリのコードには「ここで頼んでいる」箇所が残ります。

境界を越えるきっかけ表

項目              システムコール
きっかけ          アプリが自分で出す依頼
使う命令          依頼専用の命令
内側の認識        頼んだことを知っている
越える境界        ユーザーモード → カーネルモード

具体例 B

VM exit

ゲストOSは普通の特権命令を実行します。頼んではいません。ハードウェアがその普通の振る舞いを差し替え、制御をハイパーバイザへ移します。ゲストのコードを読んでも、どこで外へ抜けるかは書かれていません。

境界を越えるきっかけ表

項目              VM exit
きっかけ          ゲストが出した普通の特権命令
使う命令          専用でない。普段の命令のまま
内側の認識        non-root であるビットは無い
越える境界        VMX non-root → VMX root

システムコールと VM exit。同じ「境界を越える」でも、何が同じで何が違うでしょうか。

「内側のコードを読めば、境界を越える箇所が分かるか」を両方で考えてみてください。

実務の場面CI で docker run が失敗し、エージェントが「CI ランナー内で VM を起動して解決」と提案した

提案は筋が通って見えます。コンテナで足りないなら、その中にVMを立てればよい、と。しかし先に確かめるべきことが1つあります。

そのランナーに、捕まえる側がいるかどうかです。KVM を使うVMは open("/dev/kvm") から始まります。ls -l /dev/kvm で何も出なければ、特権命令を捕まえる経路が開いていません。CPU が vmx や svm を持っていても、コンテナにそのデバイスが渡されていなければ同じです(grep -c -E 'vmx|svm' /proc/cpuinfo と ls -l /dev/kvm は別のことを見ています)。

「起動して解決」という文の前に、その環境で起動できるのかという問いが要ります。判断材料は1行の ls で、実行に数秒もかかりません。

この章のまとめ

VMの中のOSは書き換えられていない。自分が最上位だと思って特権命令を出す。
その命令はハードウェアが捕まえる。Intel の語では、ゲストが VMX non-root、VMM が VMX root で動き、non-root → root の遷移が VM exit、root → non-root が VM entry(SDM 325384-092US, June 2026 §26.3)。AMD では VMRUN と #VMEXIT(APM Rev.3.23 §15.5・§15.6)。
「Ring −1」は Intel/AMD の用語ではない。 両文書の全文に現れない。SDM はむしろ「ゲストは本来設計された特権レベルのまま動ける」と書いている。
Popek と Goldberg の efficiency(§5)が「無害な命令はハードウェアが直接実行する」を要求するので、全命令をソフトウェアで見張る方式は除かれる。
システムコールと VM exit は「外側が代わりに処理する」点で同じ、「依頼があるか」で違う。
Linux では捕まえる側の入口が /dev/kvm。無ければ、そこでVMを起動する話は成り立たない。

次は、捕まえられたゲストのメモリがどう扱われるかを見ます。関連するクイズは『仮想化とコンテナ隔離の原理』の「仮想化I(ハイパーバイザとハードウェア支援)」にあります。

自分の現場で確かめる

読んだだけでは身につきません。手元の環境で実際に見てみてください。

環境:

この機械が「捕まえる側」になれるかを確かめるWindowsでは確認できません。この項目はLinux/WSLで試してください。
手元の環境で /dev/kvm があったかどうかを、CI のランナーでも同じように確かめてみる。無ければ、そこで VM を起動する提案は成り立たない
Intel SDM Vol.3 を開き、VMX の導入章が自分の版では第何章になっているかを目次で確認する(版によって章番号が動く)

理解度チェック

読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。

問題 1 / 4正解: 0

Intel SDM が VMX operation の2種として挙げている名前の組み合わせはどれですか。

用語集(5語)

VMX root operation / VMX non-root operation: Intel のプロセッサ動作の2形態。VMM が root、ゲストソフトウェアが non-root で動く。non-root では特定の命令とイベントが VM exit を起こす。SDM Vol.3(325384-092US, June 2026)§26.3。
VM entry / VM exit: root と non-root の間の遷移。non-root へ入るのが VM entry、non-root から root へ戻るのが VM exit。VM exit は VMM が指定した入口へ制御を移す。
#VMEXIT(AMD): AMD SVM での同等の動き。インターセプトが発火するとプロセッサが #VMEXIT を行い、ゲストからホスト文脈へ抜ける。理由は VMCB の EXITCODE フィールドに保存される(APM Vol.2 Rev.3.23 §15.6)。
sensitive 命令 / privileged 命令: Popek と Goldberg の定理1 が使う区別。sensitive 命令の集合が privileged 命令の集合の部分集合であれば、その機械に VMM を構成できる。
/dev/kvm: Linux の KVM サブシステムへの入口となるデバイスファイル。カーネル文書は「An initial open("/dev/kvm") obtains a handle to the kvm subsystem」と書いている。これが無い環境では KVM を使う VM は起動しない。

ハイパーバイザ — 特権命令をどう捕まえるか