11

ARMv7（Cortex-a8）用にコンパイルされたLinuxカーネル2.6.34.3

カーネルコードを調べたところ、LinuxカーネルがTTB1（変換テーブルベース）のカーネルアドレススペース（0xC0000000を超えるすべて）とttb0（0xC0000000未満のすべて）のユーザープロセスのハードウェアページテーブルを設定しているようです。プロセスコンテキストスイッチ。これは正しいです？MMUが翻訳のためにどのttbを調べるべきかをどのように知っているのかまだ混乱していますか？

TTBCR（変換テーブルベース制御レジスタ）は、MVAが見つからない場合にどのttbレジスタをウォークするかを決定することを読みましたが、レジスタは常に0を読み取ります。これは、ARMアーキテクチャリファレンスマニュアルで常にTTBR0を使用することを意味します。そんなことがあるものか？Linuxカーネルがこれら2つのttbsをどのように使用するかを誰かに説明してもらえますか？

このサイトhttps://www.cs.rutgers.edu/~pxk/416/notes/10-paging.htmlからttbがどのように機能するかを読みましたが、カーネルが2つのttbをどのように使用するかはまだわかりません。

（カーネルコードを再確認しました。何らかの理由でttb0とttb1の両方が設定されていますが、ttb1が使用されていないようです。TTB1レジスタを0に設定すると、Linuxカーネルは通常どおり実行されます）

4

4 に答える 4

1

私はARMアーキテクチャについてほとんど知識がありませんが、同封のリンクで読んだことから、Linuxは仮想メモリ管理をそのように実装していると思います：

どちらを使用するかは、仮想アドレスの上位ビットによって決まります。テーブルのベースは、仮想アドレスの最上位 n ビットが 0 (TTBR0 を使用) かそうでないか (TTBR1 を使用) に応じて、2 つのベース レジスタ (TTBR0 または TTBR1) のいずれかに格納されます。n の値は、変換テーブル ベース制御レジスタ (TTBCR) によって定義されます。

レジスタTTBCRは、TTBR0またはが指すページ テーブルからどのアドレスが変換されるかを示しTTBR1ます。TTBCRが含まれている場合0xc000000、 から0までのアドレス0xbfffffffは が指すページテーブルによって変換され、 からまでTTBR0のアドレスはが指すページテーブルによって変換されます。これは、ユーザー プロセス用の 3GB / カーネル用の 1GB の Linux メモリ分割に一致します。0xc00000000xffffffffTTBR1

これにより、オペレーティング システムとメモリ マップド I/O がアドレス空間の上部に配置され、TTBR1 のページ テーブルによって管理され、ユーザー プロセスがメモリの下部にあり、ページ テーブルによって管理される設計が可能になります。 TTB0 のページ テーブル。コンテキスト スイッチでは、オペレーティング システムは TTBR0 を変更して、新しいプロセスの第 1 レベルのテーブルを指すようにする必要があります。TTBR1には、オペレーティング システムのメモリ マップとメモリ マップ I/O が含まれます。

TTBR1したがって、カーネルを永続的にマップする必要があるため、 の値は決して変更しないでください (割り込みが発生したときに何が起こるかを考えてください)。一方、TTBR0プロセス切り替えごとに変更され、現在のプロセスのページテーブルが含まれています。

于 2013-01-22T17:05:10.440 に答える
1

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0211k/Bihgfcgf.htmlを参照してください。

ARM5 以下の場合、TTB テーブルのサイズと位置合わせは固定されています (16k まで)。各レベル 1 エントリは 1MB を表します。テーブル エントリは 32​​ ビット (16k*1M/(32 ビット/8) = 4GB) です。TTBCRはTTBR0テーブル サイズを制御します。上記URLより、

使用する変換テーブル ベース レジスタの選択
変換テーブル ベース レジスタは次のように選択されます
。N = 0 の場合、常に変換テーブル ベース レジスタ 0 を使用
します。 - これはリセット時のデフォルト ケースです。ARMv5 以前のプロセッサとの下位互換性があります。
N が 0 より大きい場合:
- 仮想アドレスのビット [31:32-N] がすべて 0 の場合は、変換テーブル ベース レジスタ 0 を使用します。それ以外の場合は、変換テーブル ベース レジスタ 1 を使用します。

したがって、TTBR0のサイズもメモリ分割を設定します。従来のLinux 3G/1G 1G/3G では、値2を選択する必要があります。4kB テーブル == 1G メモリ == ビット 31..30 はゼロです。値が6の場合、テーブルは 256 バイト == 64MB == ビット 31..26 はゼロです。

Linux の用語では、これらはページ グローバルエントリです (これにより、このページ グローバルディレクトリが分割されます)。エントリは、別のテーブルを指すことも、1MBのセグメントのみを指すこともできます。次のテーブル エントリは、ページ中央の Linux ディレクトリであり、最後のページ テーブルエントリです。ページの中間エントリは ARM では使用されていないと思います。

MMU ハードウェアは、毎回テーブルを移動するわけではありません。TLB（翻訳ルックアサイドバッファ）があります。これは、MMU テーブルのキャッシュのようなものです。OS がこれらのテーブルを更新するときは、TLB をフラッシュする必要があります。フラッシュしないと、プロセッサが古いエントリを使用します。同様に、ARM キャッシュは仮想タグ付きであるため、マッピングを変更すると、キャッシュをフラッシュする必要があることも意味する場合があります。これらの理由から、コンテキスト スイッチで何かを変更したくはありません。共有ライブラリ テキスト ( libc.soなど) は、コンテキスト スイッチで同じにする必要があります。各プロセスが同じ仮想アドレスにマッピングされた libc.so を持っていることを願っています。これを行うことには大きな利点があります。メモリの使用量が少なく、I キャッシュの使用量が多い。

ドメインとPIDレジスタ、およびスーパーバイザ/ユーザー モードもメモリ アクセスを制御できます。これらは、コンテキスト スイッチで切り替えることができる単一のレジスタです。

ARMV5での PID とドメインの使用に関する情報については、http://lwn.net/images/conf/rtlws11/papers/proc/p01.pdf を参照してください。現在の Linux ソースは、論文で説明されているとおりには動作しません。Linux がこのメカニズムを使用する必要がなく、TTBCRを 0 に設定して、ARM サブアーキテクチャの VM コードが類似している可能性は十分にあります。

編集: TTBCR機能を使用して 3G/1G 分割を実現できるとは 思いません。Rutger のページでは、 Linuxのコンテキストではなく、一般的にTTBCRについて議論していたと思います。また、少なくとも2.6.38 Linux はドメインまたはDACRを使用していましたが、限られた数のプロセスをサポートする ため、 pidまたはfcseを使用していません。

http://lwn.net/Articles/106177/ - ラトガースのページでも参照されています。

于 2013-01-22T20:21:52.583 に答える