ページ違反の後に何が起こりますか？
Linuxシステムでページ違反が発生した場合、割り込みハンドラーは、ページ違反が発生した理由を解明する必要があります。しかし、どうやって？
- そのための特別な番号はどこにありますか！？はいの場合、その番号はどこに記録されますか？
- 例外を発生させる前にページフォルトの理由を知ることは可能ですか？
例えば。- ステップ1
CPUによる理由を探します - ステップ2
例外を上げる
- ステップ1
仮想アドレスのMMUルックアップが無効な記述子またはアクセス許可の欠如を示す記述子（読み取り専用ページへの書き込み試行など）で終了したためにメモリアクセスが失敗すると、ページフォールトが発生します。ページ違反が発生すると、プロセッサはいくつかのアクションを実行します。詳細は各プロセッサアーキテクチャに固有ですが、要点は同じです。
- 特権モード（カーネルモードなど）に切り替えます。
- 少なくとも障害の性質、および障害発生時のプログラムカウンタとプロセッサモードを示すようにいくつかのレジスタを設定します。
- レジスタによって示されるメモリ内の特定のアドレスにジャンプするか、メモリ自体の特定の場所（ページフォールトハンドラのアドレス）を調べました。
例として、（32ビット）ARMプロセッサで：
dfsrレジスタは、障害を説明する値に設定されます（それが読み取りによるものか、書き込みによるものか、プロセッサ命令またはDMAなどによるものか）。dfarレジスタは、障害の原因となったアクセスのターゲットであった仮想アドレスに設定されます。- プロセッサが abort mode （カーネルレベルの特権 modes ）の1つに切り替わります。
lrレジスタは、障害発生時にプログラムカウンタに設定され、spsrレジスタはプログラムステータスレジスタ（cpsr、障害発生時のモードビットなど）。spおよびcpsrレジスターはバンクされています。これらは、アボートモードで最後に設定された値から復元されます。- 実行は、 例外ベクトル の1つである中止ベクトルにジャンプします。
ページフォールトハンドラーのコードは、オペレーティングシステムのカーネルの一部です。その仕事は、障害の原因を分析し、それについて何かをすることです。障害の性質に関する情報を提供する専用レジスターを調べ、必要に応じて、プログラムが実行していた命令を検査することもできます。 MMUテーブルで記述子を検索することもできます。無効な記述子は、スワップ空間内のページの場所などの情報をエンコードすることがあります。カーネルは、各コンテキストスイッチで更新するグローバル変数またはレジスタの値を調べることで、現在実行中のタスクを認識します。次に、ページフォールトでのいくつかの一般的な動作を示します。
- プロセスのメモリマッピングに関するデータは、ページがスワップされていることを示しています。カーネルはスペアの物理ページを見つけるか、ディスクキャッシュを含むページを削除してページを取得するか、最初にその内容をスワップに保存してページを取得します。次に、スワップからこの物理ページにデータをロードし、MMUテーブルを変更して、障害の原因となった仮想アドレスがプロセスのMMUのその物理ページにアタッチされるようにします。地図。最後に、カーネルは、障害を引き起こした命令のポイントでプロセスに戻るように調整します。今回は命令が正常に実行されます。
- プロセスのメモリマッピングに関するデータは、ページがコピーオンライトページであり、書き込みアクセスが試行されたことを示しています。前のケースと同様に、カーネルはスペアの物理ページを取得し、そこにデータをコピーし（ここでは、読み取り専用のページから）、MMU記述子を変更して、プロセスが実行するように調整します。再び命令。
- プロセスのメモリマッピングに関するデータは、ページがマップされていないか、ページに必要な権限がないことを示しています。その場合、カーネルはSIGSEGVシグナル（セグメンテーション違反）をプロセスに配信します。プロセスの実行は、元の場所ではなくシグナルハンドラーで再開されますが、元の場所はスタックに保存されます。プロセスにSIGSEGVのハンドラがない場合、プロセスは終了します。
仮想メモリの構成を理解し、メモリアクセスの前にチェックを行うことを除いて、例外が発生しようとしていることを特定することは、一般的には不可能です。通常の動作フローでは、ページフォールトが発生したときに、プロセッサによってページフォールトの理由が記録されます。