64비트 Linux 커널은 호환 모드에서 32비트 응용 프로그램의 페이지 테이블을 어떻게 관리합니까?

현재 저는 "Linux 커널 이해"라는 책을 읽고 있습니다. 그 중에는 다음과 같은 진술이 있습니다.

물리적 주소 확장이 없는 32비트 아키텍처의 경우 두 개의 페이징 수준이면 충분합니다. Linux에서는 기본적으로 Directory-on-Page 및 Directory-in-Page 필드가 0비트를 포함하므로 제거됩니다. 그러나 포인터 시퀀스에서 페이지 상위 디렉터리와 페이지 중간 디렉터리의 위치는 유지되므로 동일한 코드가 32비트 및 64비트 아키텍처에서 작동할 수 있습니다. 커널은 페이지의 상위 디렉토리와 페이지의 중간 디렉토리의 항목 수를 1로 설정하고 이 두 항목을 페이지의 전역 디렉토리에 있는 올바른 항목에 매핑하여 페이지의 상위 디렉토리와 페이지의 중간 디렉토리의 위치를 ​​보존합니다.

따라서 4단계 페이징 수준을 갖춘 64비트 Linux 커널의 페이지 테이블 계층 구조는 다음과 같습니다.

PML4 (Linux: PGD) -> 512 * PDPT (Linux: PUD) -> 512 * PD (Linux: PMD) -> 512 * PT

따라서 텍스트에서는 두 가지 수준이면 충분하다고 합니다(일반적인 32비트 페이징과 마찬가지로). 이것이 바로 PUD와 PMD가 "제거"되는 이유이지만 이 두 테이블 중 하나의 길이가 1이고 시퀀스에서 올바른 순서를 저장합니다. .
내 이해에 따르면 이는 PML4(PGD)가 PD(PMD)에 해당하고 PT에 대한 직접 포인터로 구성된다는 의미입니다. 따라서 PUD 및 PMD는 "건너뜁니다". 하지만 이는 올바르지 않은 것 같습니다. 모드를 커널 모드로 전환한 후 커널 페이지에 액세스하려면 64비트 페이지 테이블을 사용하여 페이징을 수행해야 하기 때문입니다. 또한 이 매핑 구성표는 4GB 경계(예: 커널 페이지)를 초과하는 메모리 매핑을 허용하지 않습니다.
또 다른 설명은 32비트 주소가 64비트로 0 확장되고 계층 구조의 처음 두 테이블에 대해 첫 번째 항목이 사용된다는 것입니다. 그런 다음 나머지 비트를 사용하여 나머지 두 테이블의 항목과 페이지 프레임 내의 오프셋을 선택할 수 있습니다. 그러나 각 테이블 항목의 비트 수가 32비트 모드와 64비트 모드에서 다르기 때문에 이것도 정확하지 않은 것 같습니다. 따라서 이로 인해 문제가 발생할 수도 있습니다.
그렇기 때문에 제가 고려하지 못한 부분이 있었나 봐요. 누군가가 상황을 명확히 할 수 있기를 바랍니다.