☰

mtrr_type_lookup()을 호출한 후에만 통일성을 확인하세요.

tag-icon • tag-icon kernel memory bios
mtrr_type_lookup()을 호출한 후에만 통일성을 확인하세요.

검사 메커니즘이 변경된 이유는 무엇입니까? MTRR 코드 업그레이드 때문인가요? 아니면 이전 점검에 문제가 있었나요?

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/x86/mm/pgtable.c?h=v6.5.7&id=12f0dd8df14285a5604f35ed3af8b8c33e8fd97f

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가 제안한 것으로 표시되었습니다.

(이 경우 추천으로 간주되는 이메일을 찾으려면,제안자가 패치 작성자에게 보낸 이메일을 찾으세요..)

관련 정보