X



NGワード絞り込みスレッド06

2025/04/04(金) 01:44:02.744767
まいなすさんびゃくななじゅうろく
BBR-MD5:CoPiPe-f44851a9dc198591948d37fad31a59bb(NEW)
BBS_COPIPE=Lv:0
PID: 54700
Inq-ID: agr/92aa07421d99e378
Proc: 0.467179 sec.
This is Original

2025/04/05(土) 00:26:19.491464
まいなすさんびゃくななじゅうご
BBR-MD5:CoPiPe-10552b97a52cf8495c4aeab02a66d324(NEW)
BBS_COPIPE=Lv:0
PID: 15150
Inq-ID: agr/92b1d2c879acfd4c
Proc: 0.461327 sec.
This is Original

2025/04/05(土) 23:24:32.054415
【メモ:32bitホストOS上で64bitゲストOSが動く仕組み】
Intel VT(またはAMD-V、以下同)がONの場合、物理CPUはホストOSのコードとゲストOSのコードを別々のContextで実行します。
例えばホストOSのコードを実行していた物理CPUが、それを中断してゲストOSのコードを実行する場合には、
事前に以下の手順で毎回Context Switchをしています。(ゲスト側→ホスト側に状態遷移する場合も同様)
 (1)現在のCPU状態をメモリに保存する → (2)前回保存したゲスト側のCPU状態を復元する → (3)ゲスト側のコードの実行を再開する。
そのため、32bitホストOSと64bitゲストOSのコードが干渉せずに分離/共存できるわけです(←細かい部分は自信なし)。
ただし仮想化ソフトウェア自体のメモリ管理機構は32bitホスト側で動作するので、3GBの壁が存在します。
(参考:これを読めばイメージがつかめるはず→)://gihyo.jp/dev/serial/01/vm_work/0005

(補足1)Intel VTがONの場合は、ゲストOS上の「そのまま動かすとマズいCPU命令」を全てHardwareレベルでTrapできます。
 そのため、Softwareレベルの事前検証が不要となり、ゲストOSのコードをそのまま物理CPUに流し込めます。
 (もちろん一部のCPU命令がTrapされてSoftwareレベルで事後補正されるので、若干のオーバーヘッドは発生します)
マシンパワー的にはi7-3770ならNT6.1ゲストの2台同時稼働は余裕ですし、C2D機でもantiX-22ゲスト(←XP並みに軽量)なら実用動作が狙えます。

(補足2)Intel VTがONの場合は、ゲストOS上のカーネルモードのコードを、物理CPUは特権レベル(リング0)で直接動かします。
 そのため、ホスト機の物理メモリ全体にゲストOS上からアクセスできそうな気もします。
 しかし、そのようなマズい命令はHardwareレベルでTrapされてHypervisorがSoftwareレベルで事後補正します。
(逆に言えば、ホストOSの代わりにHypervisorがメモリ管理をすれば「ホストOSが使えないメモリをゲストOSが使える」かも(←内容が正しいかは自信なし))
BBR-MD5:CoPiPe-3019454b1abe66bc0cc0cd8f4d52d249(NEW)
BBS_COPIPE=Lv:0
PID: 83093
Inq-ID: agr/92b9b583b85cfcb9
Proc: 0.468964 sec.
This is Original

2025/04/06(日) 00:33:18.377757
まいなすさんびゃくななじゅうさん
BBR-MD5:CoPiPe-5fbc81ab34b3f4ea3fb75762ff344b73(NEW)
BBS_COPIPE=Lv:0
PID: 6047
Inq-ID: agr/92ba1a62f85c0b25
Proc: 0.476499 sec.
This is Original

2025/04/07(月) 00:37:57.070175
まいなすさんびゃくななじゅうに
BBR-MD5:CoPiPe-6649ffc94e8bd866208e1f76970453e6(NEW)
BBS_COPIPE=Lv:0
PID: 98594
Inq-ID: agr/92c25e907f03dfc5
Proc: 0.474475 sec.
This is Original

レスを投稿する

5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。

ニューススポーツなんでも実況