検査メカニズムが変更されたのはなぜですか？ MTRRコードのアップグレードのためですか？それとも以前のチェックに問題がありましたか？
x86/mm: Only check uniform after calling mtrr_type_lookup()
Today pud_set_huge() and pmd_set_huge() test for the MTRR type to be
WB or INVALID after calling mtrr_type_lookup().
Those tests can be dropped as the only reason not to use a large mapping
would be uniform being 0.
Any MTRR type can be accepted as long as it applies to the whole memory
range covered by the mapping, as the alternative would only be to map
the same region with smaller pages instead, using the same PAT type as
for the large mapping.
ベストアンサー1
意味が正しくないため、コードが変更されましたuniform。これはパッチセットの初期反復で見られた。ウィルゲン・グロスが尋ねた。
大規模なマッピングが複数のMTRRにまたがる場合、同じキャッシュタイプを定義しても問題が発生する可能性があります（この場合、ユニフォームは0に設定されます）。
だから私に基本的な質問は：制服の意味を調整する必要がありますか？今日、これは「範囲が単一のMTRRによってカバーされるかどうか」を意味します。ユースケースを見ると、「フルスコープに対して同じキャッシュタイプ」ではないはずです。
どちらにリヌス・トバルズが答えた。
ああ、制服を1に直すべきだと思います。
IOW、「マルチMTRR」が「統合されていない」という意味ではないと思います。 「実際のメモリタイプが異なる」とは、不一致を意味する。
私の記憶が正しいなら、MTRRが重なっている理由はありません。実際に奇妙なメモリ設定がある場合は、連続していないメモリの種類を説明するMTRRを作成できます。
インテルは、MTRR 操作がネストされる方法を明確に定義し、「同じタイプのネスト」が実際に文書化されています。
これにより、お客様がリクエストしたパッチが作成され、Linus が提案したものとマークされました。
(この場合、おすすめと見なされるメールを検索するには、プロポーザルがパッチ作成者に送信したメールを見つけます。.)