最初の3GBはプロセス用に予約されており、最後のGBはカーネル用に予約されていることを読みました。また、カーネルは物理アドレス空間の2番目のMBからロードされることも読みました（構成によって異なります）。私の質問は、最後の1 GBのマッピングはすべてのプロセスで同じであり、この物理的なメモリ領域にマッピングされるということですか？
もう1つの質問は、プロセスがカーネルモードに切り替わるとき（たとえば、sys呼び出しが発生するとき）、どのページテーブルが使用されるか、プロセスページテーブルまたはカーネルページテーブルですか？カーネルページテーブルが使用されている場合、プロセスに属するメモリ位置にアクセスできません。その場合、カーネルコードとデータへのすべてのアクセスは、プロセスアドレス空間の最後の1 GBのマッピングを介して行われるため、カーネル仮想メモリは明らかに使用されません。これを明確にするのを手伝ってください（有用なリンクがあれば大歓迎です）
32 ビット x86 システムについて話しているようですね。
私が間違っていなければ、カーネルは 3Gb/1Gb メモリ分散だけでなく、他のバリアント (2Gb/2Gb など) も構成できます。それでも、x86-32 ではおそらく 3Gb/1Gb が最も一般的です。
アドレス空間のカーネル部分は、ユーザー空間からアクセスできないようにする必要があります。カーネルの観点からは、はい、カーネル自体が占有するメモリのマッピングは常に同じです。関係なく、カーネルが現在動作しているプロセス (または割り込みハンドラーなど) のコンテキストで。
結果の 1 つとして、/proc/kallsyms異なるプロセスからのカーネル シンボルのアドレスを見ると、毎回同じアドレスが表示されます。これらは、カーネルの観点から見た、それぞれのカーネル関数、変数、およびその他の正確なアドレスです。
最初の質問への答えは「はい」だと思いますが、カーネル空間のメモリにはそこから直接アクセスできないため、ユーザー空間のコードにはおそらくあまり役に立ちません。
2 番目の質問については、カーネルが現在何らかのプロセスのコンテキストで動作している場合、そのプロセスのユーザー空間メモリに実際にアクセスできます。詳しく説明することはできませんが、おそらくカーネル関数の実装であり、copy_from_userいくつcopy_to_userかのヒントを与えることができます。カーネル ソースのarch/x86/lib/usercopy_32.cとを参照してください。arch/x86/include/asm/uaccess.hx86-32 では、現在のプロセス コンテキストのデフォルトのメモリ マッピングを使用して、これらの関数でユーザー空間メモリに直接アクセスしているようです。そこにある「魔法の」ものは、最適化とメモリ領域のアドレスの正確さのチェックにのみ関連しています。
はい、アドレス空間のカーネル部分のマッピングはすべてのプロセスで同じです。 その一部は、カーネル イメージがロードされる物理メモリのその部分をマップしますが、それは大部分ではありません。残りは、カーネルのランタイム ワーキング セットの他の物理メモリの場所をマップするために使用されます。
プロセスがカーネル モードに切り替わるとき、ページ テーブルは変更されません。CPL (現在の特権レベル) が 0 になったため、アドレス空間のカーネル部分にアクセスできるようになります。