Adding new mappings in pagetable doesn't require TLB flushes

オープン
#587 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
45/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
静か
技術スタック
rust

調査の方向性

MappedPageTable および同様のマッピング機構を追跡し、MapperFlush の戻り経路と、すでに存在するマッピングの処理に焦点を当てます。引用されている Intel paging specification を読み、ページテーブルへの書き込みが後続のマッピング使用に対してどのような順序になっているかを調べます。新しいマッピングでは TLB flush が不要になり、既存のマッピングでは引き続きエラーが発生し、書き込みが安全な順序で行われることが完了の条件です。

索引モデルが issue の本文から書いたものです。

説明

Currently, MappedPageTable and similar facilities always return MapperFlush when mapping a new page, and return a error is a mapping already exist.

According to Intel specifications, adding new mappings to a pagetable doesn't require a TLB flush.

If a paging-structure entry is modified to change the P flag from 0 to 1, no invalidation is necessary. This is
because no TLB entry or paging-structure cache entry is created with information from a paging-structure entry
in which the P flag is 0.

Although, for that to be correct, we still need to ensure that the pagetable entry is actually written at the end of the mapping function (currently, this is somehow enforced by the expected tlb flush that does inline asm invlpg without the nomem attribute), otherwise the compiler is allowed to do surprising reordering of the pagetable modification to e.g after the use of the mapping we're looking to make.

主要言語
Rust
スター
942
フォーク
162
平均マージ
1日 13時間
マージ済み PR(30日)
2

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

rust-osdev/x86_64 のほかの issue

rust-osdev/x86_64 の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。