私は、次のような制約を持つことになり、非常に薄いハイパーバイザーを記述しようとしています：時OSのメモリ分離
私はインターネットを検索しましたが、できるだけオーバーヘッドを抑えたいので、この特定の問題については何も近くに見つかりませんでした（現在のハイパーバイザの実装は私のニーズに合っていません）。
は、必ずしも幾分不完全であるいくつかの提案/ヒントです。
ハイパーバイザーを最初に「マルチブート対応」にしてください。これにより、ブートローダの設定ファイル（例えば、/boot/grub/menu.lstまたは/boot/grub/grub.cfg）の典型的なエントリとして存在します。
のトップには、メモリが最大でで100MBを確保する必要があります（例：5.9GBから6GBまで）。 Windowsについて言及して以来、私はあなたがx86アーキテクチャに興味があると仮定しています。 x86の歴史が長いことは、最初の数メガバイトがすべての種類のレガシーデバイスの複雑さで満たされていることを意味します。 640Kと1MBの間にある "穴"については、ウェブ上に多くの資料があります（これについて詳述しているウェブの情報がたくさんあります）。古いISAデバイス（その大部分は「Super I/Oチップ」の現代システムではまだ生き残っています）は、最初の16 MBの物理メモリまでDMAを実行することに制限されています。 WindowsやLinuxの間に侵入しようとすると、これらの最初の数MBのRAMとの関係では、それほど複雑になるでしょう。あなたがブーツを持っていれば、後でそれを保存してください。
物理アドレスが4GB（2^32、基本的な32ビットアーキテクチャの物理メモリの制限）に近づくにつれて、この領域には多くのデバイスがメモリマップされています。たとえば（他の回答を参照）、IntelがVT-d技術を提供しているIOMMUでは、構成レジスタが0xfedNNNNNで始まる物理アドレスにマップされる傾向があります。
これは、複数のプロセッサを搭載したシステムでは2倍に当てはまります。私はあなたがユニプロセッサーシステムから始めるか、BIOS内から他のプロセッサーを無効にするか、あるいは少なくとも手動でゲストOSを構成して他のプロセッサーを有効にしないようにすることをお勧めします（例えば、Linuxの場合、 'nosmp'をカーネルコマンドラインに含めます。 、あなたの/boot/grub/menu.lstにあります）。
次に、「e820」マップについて学びます。繰り返しますが、ウェブ上にはたくさんの資料がありますが、おそらく、Linuxシステムを起動し、出力 'dmesg'の一番上を見ることが最善の場所です。これはBIOSが物理メモリ空間の一部がデバイスまたは他のプラットフォーム固有のBIOS /ファームウェアの使用（たとえば、USB I/Oポートのみのシステム上でPS/2キーボードをエミュレートするために "予約"されているOSと通信する方法です）。
ハイパーバイザーがゲストOSから100MBを「隠す」方法の1つは、システムのe820マップにエントリを追加することです。始めるには、Linuxカーネルのコマンドラインオプション "mem ="またはWindowsのboot.ini/bcdeditフラグ "/ maxmem"を使うことがすばやく簡単です。
あなたが遭遇する可能性のある詳細や事柄はたくさんあります（例えば、x86プロセッサは最初に電源投入されたときに16ビットモードで起動します）が、ここにリストされているもので少し宿題をすれば、あなたはフォローアップの質問をするより良い立場にいます。
あなたが探しているものは、すでにハードウェアに存在しています。
IOMMU [1]と呼ばれています。基本的には、ページテーブルのように、実行された命令と実際の物理ハードウェアの間に変換レイヤーを追加します。
AMDはIOMMU [2]と呼んでいますが、IntelはVT-dと呼んでいます（google： "intel vt-d"まだ3つ以上のリンクを投稿できません）。
からスクラッチハイパーバイザーを開発することは複雑な作業である[1] http://en.wikipedia.org/wiki/IOMMU
[2]ここhttp://developer.amd.com/documentation/articles/pages/892006101.aspx