x86_64のLinuxでメモリマッピングIOでマスクされた「失われた」物理メモリを回復する方法は?

x86_64のLinuxでメモリマッピングIOでマスクされた「失われた」物理メモリを回復する方法は?

/proc/iomemマイコンピュータのビデオカードなどのPCIデバイスにマッピングされた重要なアドレス空間を表します。e0000000-efffffff : 0000:01:00.0私の計算が正しい場合は250MBです。 RAMがわずか16GBの64ビットデスクトップでは、Linuxまたはすべての最新のカーネルがいくつかのトリックを使用して物理メモリのこの部分を回復できるとします。しかし、正確にどうなりますか?

やや関連する質問 - ノースブリッジ/メモリコントローラがプログラム可能な規則に従ってメモリ/ IOアクセスをルーティングして、メモリマップされた領域(pciデバイスなど)への書き込みアクセスの場合、RAMはこれらの書き込みについて知りません。ルーティングがなくなったので、一種の「ルーティングテーブル」があるはずですか?そのようなテーブルはどこにありますか? Linuxカーネルはこのテーブルにどのようにアクセスしますか?

答え1

私はこのトピックに関するいくつかのwikiページを見つけました。PCI_ホールそして3_GB_バリア

現在x86では、PCIの脆弱性はメモリの再マッピングとして扱うことができますが、16M未満のいくつかの小さな領域など、MMIOが盗んだすべてのRAMアドレスを回復するわけではありません。チップセットには、限られた数の領域のみを再マッピングする機能しかありません。

答え2

64ビットオペレーティングシステムを使用しているため、BIOS設定「4G以​​上のデコード」、「64ビットI / Oアドレスのデコード」、またはシステム/マザーボードベンダーから呼び出すすべての項目を有効にできます。この設定を有効にすると、64ビットアドレスを処理できるすべてのMMIOハードウェアが既存の32ビット範囲外のアドレスにマッピングされ、メモリの競合を最小限に抑え、スロットを再マッピングする必要性を減らします。

私のシステムでは、結果のGPUマップは次のようになります。

6000000000-600fffffff : 0000:01:00.0

さらに、250MBは16GBの約1.5%に過ぎません。最後の1.5%のメモリを確保することが本当に重要な場合は、可能であればより多くのRAMを確保すると、大きなパフォーマンス上の利点が得られます。ただの言葉です...

私が知る限り、メモリの再マッピングに使用される「ルーティングテーブル」は、少なくとも部分的にチップセットハードウェアに実装され、チップセットによって異なるため、通常は起動時にシステムファームウェアによって設定されます。ランタイムアクセスがある場合は、ACPIファームウェアルーチンを介してアクセスしたいと思います。それ以外の場合、カーネルは各チップセットに特定のルーチンを提供する必要があります。

(はい、カーネルには既知のハードウェアバグを解決するための奇妙なハードウェアモデル固有のルーチンがありますが、それより深く入り、システムファームウェアが提供するACPI抽象化をバイパスするにはより多くの労力が必要です。コアガイドライン.)

関連情報