안녕하세요. page table mapping 과정에서 모르는 부분이 있어 질문 드립니다.

질문을 요약하면, 아래 compute_indices가 "일반적인 상황에서" 사용되기에는 부적합해 보이는데

제가 생각한 것이 맞는지 궁금합니다.

 

 linux-5.1.16/arch/arm64/kernel/head.S:218

1    .macro compute_indices, vstart, vend, shift, ptrs, istart, iend, count
2    lsr    \iend, \vend, \shift
3    mov    \istart, \ptrs
4    sub    \istart, \istart, #1
5    and    \iend, \iend, \istart    // iend = (vend >> shift) & (ptrs - 1)
6    mov    \istart, \ptrs
7    mul    \istart, \istart, \count
8    add    \iend, \iend, \istart    // iend += (count - 1) * ptrs
9                    // our entries span multiple tables

10  lsr    \istart, \vstart, \shift
11  mov    \count, \ptrs
12  sub    \count, \count, #1
13  and    \istart, \istart, \count

14  sub    \count, \iend, \istart
15  .endm

 

compute_indices는 page table이 몇 개의 entry를 가지게되는지 계산하는 매크로입니다.

map_memory 매크로는 각 페이지 테이블 단계별로 compute_indices를 호출합니다. (최대 4번)

VA 48bit, page size 4K 일 때 4단계 매핑한다고 설정하고 값을 계산해보려 합니다.

주소는 편의상 binary로 표현했습니다.

 

0b000000000_111111111_111111111_111111111_000000000000 (시작 주소)

0b000000001_000000000_000000000_000000000_111111111111 (마지막 주소)

이렇게 하면 사이즈는 8K입니다.

 

PGD를 계산하기 위해 compute_indices가 처음 호출되면 (호출시 count = 0),

최상위 9bit를 가지고 계산하여 istart = 0, iend = 1이 되고 리턴할 때 count는 1이 됩니다.

즉 PGD의 엔트리 개수는 2개이고, 필수적으로 존재해야하는 1개의 entry 이외에

추가로 1개의 entry가 더 필요하기때문에 count = 1이 됩니다.

 

문제는 두번째로 PUD를 계산할 때 입니다. 이 때는 앞서 PGD 계산의 결과로 count = 1 입니다.

최상위 9bit를 제외한 두번째 9bit를 가지고 계산을 합니다.

istart = 0b111111111

iend  = 0b000000000

 

질문1. 8번 라인이 수행되지 않는다고 가정하겠습니다. (8번 라인은 질문2와 관련됩니다)

14번 라인에서 iend에서 istart를 빼서 count를 계산합니다.

그런데 0b000000000 - 0b111111111 = 0b1...1000000001 가 됩니다.

이 계산 결과에도 0b111111111 mask를 씌워야 하는 게 아닐까요?

즉, 14번 라인이 문제 없이 수행되려면 모든 레벨에 대해서 시작 주소의 인덱스가 마지막 주소의 인덱스보다

작아야 하는 것 아닐지요.

 

질문2. 8번 라인에서는 PGD에서 리턴된 count 값에 따라서 iend값을 늘려 줍니다.

즉, PGD에서 추가로 한개의 entry가 더 있기때문에 iend 개수는 512만큼 (하나의 페이지 분량) 늘어나게 됩니다.

그러나 이 예시에서는 두 개의 PUD에 각각 한개씩의 entry만 있어도 충분합니다.

PUD의 entry 개수에 따라서 PMD의 영역이 할당될텐데,

이런식으로 무조건 512개씩 엔트리를 늘려버리면 특정한 케이스에 대해서는 뒤로갈수록 너무 심한 공간 낭비가 될텐데요.

이렇게 계산하는 것이 적절한가요?

 

결론적으로 compute_indices의 계산 방식은 일반적인 경우에는 적용될 수 없을 것 같은데, 제 생각이 맞을지요.

실제로 id mapping을 할 때는 page table 영역을 12K만큼밖에 안잡아놓고 있고,

section mapping을 하고 PGD, PUD의 entry가 각각 1개씩밖에 없기때문에

각 레벨의 page table이 한개씩만 있어도 돼서 총 table 3개로 커버가 되는 상황이라고 이해했습니다.

즉 메모리 영역이 1G 이하일 뿐만 아니라, 제가 억지로 만든 예시처럼 주소가 상위 레벨에서 여러 페이지에

걸쳐있지 않기 때문에 문제가 없는 것 같아 보입니다.

이런 특수한 상황에서만 돌아가도록 짜여진 매크로가 맞을까요?

 

(+ idmap이 매핑하는 메모리 공간의 크기는 어떻게 확인 가능할까요?)

 

답변 부탁드리겠습니다!!

감사합니다.

번호 제목 글쓴이 날짜 조회 수
공지 [공지] 프로그래밍 관련 Q&A 게시판 입니다. woos 2016.04.09 22231
498 ___reserved_mem_reserve_reg 관련 질문 [4] DEWH 2020.03.09 12846
497 16기 리눅스 커널 스터디 33주차 질문입니다. [5] rnsscman 2020.02.08 357
496 setup_machine_fdt() -> fixmap_remap_fdt() 질문입니다. [2] daeroro 2019.12.24 316
495 early_fixmap_init 질문 [3] file 에러 2019.12.17 288
494 16기 리눅스 커널 스터디 27주차 질문입니다. [1] daeroro 2019.12.18 800
493 16기 리눅스 커널 스터디 25주차 질문입니다. [3] rnsscman 2019.12.03 367
492 16기 리눅스 커널 스터디 C조 23주차 질문입니다. [2] 이파란 2019.11.16 389
491 16기 리눅스 커널 스터디 C조 19주차 질문입니다. (두 번째) [2] rnsscman 2019.10.29 234
490 16기 리눅스 커널 스터디 C조 19주차 질문입니다. [2] 이파란 2019.10.19 400
489 asid 관련해서 질문드립니다. [3] suesueng 2019.10.21 716
488 unflatten_dt_nodes 질문 [3] file 에러 2019.10.12 214
487 16기 리눅스 커널 스터디 C조 cpu_bit_bitmap 질문 [2] sjahn 2019.10.05 244
486 16기 리눅스 커널 스터디 C조 cgroup_init_early 부분 질문 [2] 이파란 2019.09.21 261
485 16기 리눅스 커널 스터디 C조 16주차 질문입니다. [2] cien 2019.09.28 1152
484 early_fixmap_init 함수 질문 [2] 에러가왜안뜨지 2019.09.12 345
483 cgroup의 구조 및 학습 방법에대해 질문드립니다. file dfx 2019.08.25 256
» head.S의 compute_indices 관련 문의 드립니다 [3] cien 2019.07.30 292
481 system register 접근 관련 질문드립니다. [2] cien 2019.07.23 454
480 task를 죽이는 do_exit 함수의 동작 중 이해가 안되는 것이 있어 질문드립니다. [2] 코딩의노예 2019.07.10 534
479 __inval_dcache_area의 동작에 대해 질문드립니다. [2] dfx 2019.07.08 228
XE Login