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