問題タブ [mmu]

関数によって行われる次のシステムコールを考えてみましょう

size_t read(int fildes, void *buf, size_t nbytes);から unistd.h。

私が理解しているように、OSは、システムコールを行ったプロセスが、読み取りデータを置く場所の指定されたアドレス、つまり にアクセスすることを許可されていることを検証しますvoid *buf。しかし、なぜそうなのですか？このチェックを行う必要があるため、提供された住所は物理的な住所ですか? はいの場合、システム コールを実行する前に、アドレスは MMU によって物理アドレスに変換されますか? また、アクセスが許可されていないアドレスをプロセスが提供するにはどうすればよいでしょうか。プロセスのアドレス空間内の仮想アドレスを、アクセスが許可されていない物理アドレスに変換する方法がわかりません。

1) 単一レベルのページ テーブルとしましょう3) TLB
ミスが発生します
3) 必要なページ テーブルがメイン メモリにあります実行できますか？高価なハードウェアではないと思います 4) MMU 物理ページ番号を取得します (MMU は、上位 n ビットを仮想ページ番号として、下位 m ビットを物理ページ フレーム番号として保存する必要があると思います。修正してください。間違っている場合は説明してください)質問: 仮想ページ番号をキーとして、物理フレーム番号を指定したキー値マップが必要だと思います。値として。MMU がページ テーブルでキーを検索する方法。線形検索のようにそのままの場合は、非常にコストがかかります。





5) ハードウェアでは、オフセット ビットをページ フレーム番号に追加します。

最後に、物理アドレスの読み取りが発生します。

したがって、この質問は私を大いに悩ませています.MMUはページテーブルで特定のキー(仮想ページエントリ)の検索をどのように実行しますか?

コンテキスト (おそらく不要):

学習課題として、Raspberry Pi 用のミニ「OS」を実装しようとしています。

私は現在、非常に馬鹿げたメモリ管理システムを実装しています。既に MMU を有効にしており、使用可能な kmalloc を取得中です。

コードとデータ セグメントの後にマップされた既存の小さなカーネル ヒープから、既にメモリのチャンクを割り当てることができます。より多くのページをマッピングすることで、必要に応じて成長させようとしています。また、物理的に連続したチャンクを生成できる必要があります。

コードはGithubでホストされています。この質問専用のブランチとデバッグ コードがあります。これは、よく整理された、よくコメントされた、または非常に賢いコードの例ではないことに注意してください。:)

実際の質問:

データ アボートをデバッグしようとしているときに、非常に奇妙なことがわかりました。

これは私の kmalloc からのコードの一部です:

私はそれを3回実行します。結果は次のとおりです。

1 回目と 3 回目の反復は正常に見えます (ただし、next_free の値は 0 であるはずですが、0xffffffff であるため、データの中止が発生します)。しかし、私のコードは 2 番目に何をしているのでしょうか? O_o 連続して 4 回読み取られたときに、printf が chunk->next_free に対して 2 つの異なる値を出力するようにするには、どのような黒い魔術が必要ですか? O_o

データは適切に整列されており、ページはキャッシュ可能かつバッファリング不可 (キャッシュ不可にしても意味がありません) であり、コンパイラーの最適化がオンでもオフでも同じ結果が得られます。そこにデータメモリバリアを投げてみましたが、実際には何もしません。作成したアセンブリも確認しましたが、問題ないようです。

TLBの破損が原因である可能性があると思いました。新しいページをマッピングするたびに、「統一された単一のエントリを無効にする」(mcr p15, 0, %[addr], c8, c7, 1) を発行しています。それは十分ですか？

qemu でデバッグを試みましたが、使用済み物理ページのビットマップを設定するとデータが異常終了しますが、この部分は Pi では問題なく動作します。

この動作の原因についての手がかりを探しているだけです。より多くのコンテキストが必要な場合は、質問してください。ただし、私のコードは今のところ急速に変化し、多くの printf が乱雑になっています。

ETA: 最初の 2 つの printf の -O0 を使用した逆アセンブリ:

そのため、 のアドレスをchunkr3 に入れ、 a を実行してldrを取得しますnext_free。2 番目の prinf の前にもう一度実行します。コアは 1 つしかなく、DMA は実行されていないため、呼び出し間でメモリ内の値が変更されることはありません。

-O2 の場合:

そのため、引き続き で値をフェッチしますldr。そのため、両方の最適化レベルで同じ結果が得られます。

新しい編集: printfs をさらに追加しましたが、この時点で特異点が発生しているようです:

この行の後、chunk->next_free はハイゼンベルクの猫に変わります。以前は、0 として読み取られます。

構造は次のように定義されます。

chunknext重ならないでください。

「特異点線」を の下に移動すると、next->next_free = chunk->next_free2 つの値が交互に表示されなくなりますが、それでも奇妙*prev_list = nextです。しかし、next->next_free はまだ 0 に設定されています。

ARMv7 アーキテクチャのブート プログラム (ベア メタル) 中に MMU を無効にします。ARM ARM を読んで、私はこれに出くわしました。

「MMU が無効になっている場合、次の条件のいずれかが満たされると、命令をフェッチできます。

• 命令が、プログラムの単純な順次実行に必要な命令と同じ 4KB のメモリ ブロック (4KB にアラインされている) にあるか、またはそのようなブロックの直後の 4KB のメモリ ブロックにある。

• 命令は、MMU が無効化されたプログラムの単純な順次実行によって以前に命令が要求されたメモリの同じ 4KB ブロック (4KB に整列) 内にあるか、またはそのようなブロックの直後の 4KB ブロック内にあります。

解読して、指示が4KB/8KB以内に並んでいることを確認する方法を説明してくれる人はいますか? （それが私が声明を理解する方法です..）

ARMv7 VMSA MMU には、ttbr0 と ttbr1 が指す 2 組の変換テーブルがあります。ttbr0 または ttbr1 が指すテーブルによって変換に使用される仮想アドレスの範囲は、「N」フィールド TTBCR レジスタによって設定されます。

ここで、この TTBCR.N を 7 に設定すると、ttbr0 の変換テーブルがカバーするアドレス範囲は 0x00000000 ～ 0x2000000 になります。

したがって、0x2000000 の後の最初のアドレス (つまり 0x2000004?) は、変換のために ttbr1 の変換テーブルを使用します。ARMv7 VMSA の短い記述子形式に従って、変換テーブルには、セクション (1MB) 領域、スーパーセクション (16MB) マッピング領域のいずれかを含めることができます。

私の質問は、0x1600000 などのアドレス位置にスーパーセクションを配置するとどうなるかということです。

理論によれば、0x1600000 から 0x2600000 の範囲のアドレスは、物理アドレス 0x1600000 にマップされます。(しかし、変換テーブル自体が 0x2000000 で変更されるため、これは機能しませんか?)

では、このシナリオでは何が起こるでしょうか? また、この場合、ttbr1 の最初のエントリには何を配置する必要がありますか?

ボードで Cortex A8 CPU を使用しており、外部 SDRAM をアドレス空間にマップして、16M スーパーセクション0x7000_0000を使用しようとしています。0x7FFF_FFFFサイズが 256 ワードの MMU ディスクリプタ テーブル (テーブルの各エントリは0x7005_1C0E、0x7105_1C0E、.... 0x7F05_1C0E) は、オンチップ RAM の に配置され0xF801_8000ます。スーパーセクションが使用されているため、各記述子はテーブル内で 16 回繰り返されます。したがって、テーブルのサイズは 256
です。TTBCR.N は 0 です。TTBR0 には
同じアドレスが含まれています。0xF801_8000
プリフェッチ アボートを取得します。
誰かが私が欠けているものを理解するのを手伝ってくれますか?
ありがとう