前回はこちら

1. はじめに：x86プロセッサという「絶望的な戦場」

1972年にSystem/370が「完璧な欺瞞」を成立させていた一方で、1990年代後半のx86（PC）の世界は、仮想化にとってまさに「暗黒時代」でした。

当時のIntelやAMDのプロセッサは、一人の王（OS）が物理資源を独占することしか想定していませんでした。メインフレームのような「仮想モード」の境界線がハードウェアに存在しなかったのです。

仮想化できない「敏感な命令」の罠

仮想化を成立させるための鉄則は「ゲストOSが特権命令を発行した際、必ずハイパーバイザーに制御が移る（トラップされる）」ことです。
しかし、x86には「実行してもトラップ（例外）が発生しないが、仮想化環境では動作が変わってしまう（あるいはシステムを破壊する）」というセンシティブ命令が存在していました。
ハードウェアが目を光らせてくれない以上、単純な「トラップ＆エミュレーション」の手法は通用しなかったのです。

詳細なメカニズムについては、以下の記事が非常に参考になります。
x86プロセッサにおけるプロセッサ仮想化（gihyo.jp）

2. ソフトウェアの執念：バイナリ翻訳と「Ring 1」

ハードウェアが助けてくれないなら、ソフトウェアが汗をかくしかありません。1998年、VMwareはこの難題を「バイナリ翻訳」という狂気的な職人芸で解決しました。

Ring Deprivileging（特権の格下げ）

本来、OSカーネルは最高権限である Ring 0 という状態で動作します。VMwareは自らが Ring 0 を占有し、ゲストOSを一段低い権限の Ring 1 で動作させるという「格下げ」を行いました。これにより、一部の命令で意図的に例外を発生させ、制御を奪う隙間を作りました。

x86 CPU には仮想環境向けのホスト・ゲスト的な区別はありませんでしたが、OS とアプリケーションなどの動作を分けるための Ring 0～3 のレベルによる動作の区別が存在しました。
VMware は、存在したけど Windows などでは実際上使われていなかった Ring 1 を利用したのです。

バイナリ翻訳（Binary Translation）

権限を落としただけでは防げない「センシティブ命令」に対しては、実行直前にコードを書き換えるという荒業を使いました。

解析: VMM（仮想マシンモニタ）が、ゲストOSが次に実行しようとしているコードを「単なるデータ」としてスキャンします。
翻訳: 危険な命令を見つけると、それを「VMMへの安全な呼び出し」に書き換えたコピーを作成します。
実行: オリジナルのコードではなく、VMMが作成した「安全な翻訳済みコード」を物理CPUに実行させます。

「ゲストOSのコードを直接実行させることは一度もない」徹底管理

VMwareのVMMは、一種の「JITコンパイラ」のように動作します。
翻訳されたコードは 「翻訳済みキャッシュ（Translation Cache）」 という専用の領域に格納されます。VMMはCPUをコントロールし、常にこのキャッシュ領域だけを実行するように制御し続けます。
つまり、ゲストOSの元のバイナリが物理CPUでそのまま実行されることは一瞬たりともありません。
この徹底した「すり替え」こそが、ハードウェアの支援がない時代に完璧な隔離を実現した秘密です。

3. ハードウェアの救済：Intel VT-x と AMD-V の登場

2005年、ついにハードウェア側が歩み寄ります。Intel VT-x および AMD-V の登場です。これにより、VMwareが汗をかいて命令を書き換える必要はなくなりました。

VMX Root / Non-Root モード

従来のRing 0〜3とは直交する概念として、VMX Rootモード（ホスト用）とVMX Non-Rootモード（ゲスト用）が追加されました。これにより、ゲストOSは「自分はRing 0で動いている」と錯覚したまま、物理的な境界線（壁）によって隔離されるようになりました。

VMCS（Virtual Machine Control Structure）

VMとホストを切り替える際の「状態の保存先」として、VMCS というデータ構造がハードウェアで定義されました。

VM Exit: ゲストからホストへの切り替え
VM Entry: ホストからゲストへの復帰

この際、レジスタやCPU状態の保存・復旧がハードウェアによって高速に行われます。これはまさに、S/370が誇った「PSW切り替え」の現代版です。

EPT（Extended Page Tables）

メモリの仮想化もハードウェアが支援するようになりました。EPT（AMDではRVI/NPT）により、ゲストOS内の仮想アドレスから物理メモリへの変換をハードウェアが二段階で解決します。これにより、複雑で重かった「シャドウページテーブル」というソフトウェア処理が不要になりました。

さらに技術を深掘りしたい人へのリファレンス

Intelの仮想化支援機能「Intel VT」とは？: Intel VT の挙動を解説している記事
Intel® 64 and IA-32 Architectures Software Developer's Manual (Volume 3C): 仮想化支援機能（VMX）の「憲法」とも言える一次資料…らしいです！

劇的な変化の比較

項目	ソフトウェアの執念 (Late 1990s)	ハードウェアの救済 (2005〜)
隔離の手法	Ring 1 への格下げ	新モード (Guest/Host) による分離
命令の処理	実行直前のバイナリ書き換え	ハードによる自動トラップ (VM Exit)
OS の視点	自分が Ring 1 にいる違和感	自分が Ring 0 (王様) であるという確信
性能損失	命令解析による巨大な負荷	ほぼゼロ（ネイティブに近い）

4. 第2回のまとめ：物理をねじ伏せる「執念」

第2回では、ハードウェアの欠陥をソフトウェアの力（バイナリ翻訳）で覆い隠し、最終的にハードウェア自体が進化してそれを救済するまでのドラマを追いました。

しかし、物理ハードウェアの仮想化が完璧になればなるほど、新たな「無駄」が浮き彫りになります。「なぜ、10台のVMを動かすために10個のOSカーネルを起動しなければならないのか？」という問いです。

次回：第3回：【OSの仮想化】Dockerの爆速な自由と、Windowsの変貌 —— WSL 2とOCIの深層に続く。