Какой механизм стоит за P2V, макрос V2P в Xv6 - PullRequest
Новая
       94

Какой механизм стоит за P2V, макрос V2P в Xv6

0 голосов
/ 28 апреля 2018

Я знаю, что существует механизм сопоставления того, как виртуальный адрес превращается в физический.

Как и в следующем случае, линейный адрес состоит из трех частей

  1. Индекс каталога страниц
  2. Индекс таблицы страниц
  3. Смещение

Вот иллюстрация:

Page Translation Picture

Теперь, когда я взгляну на исходный код Xv6 в memorylayout.h 

#define V2P(a) (((uint) (a)) - KERNBASE)
#define P2V(a) (((void *) (a)) + KERNBASE)

#define V2P_WO(x) ((x) - KERNBASE)    // same as V2P, but without casts
#define P2V_WO(x) ((x) + KERNBASE)    // same as P2V, but without casts

Как V2P или P2V могут работать правильно, не выполняя процесс преобразования адреса?

1 Ответ

0 голосов
/ 14 мая 2018

Макросы V2P и P2V не делают больше, чем вы думаете. Они просто вычитают и добавляют константу KERNBASE, которая отмечена как 2 ГБ.

Кажется, вы правильно понимаете механизм аппаратного отображения MMU. Правила отображения сохраняются таблицами страниц процесса. Эти таблицы образуют виртуальное пространство процесса.

В частности, в XV6 структура виртуального пространства процесса строится (с помощью соответствующих отображений) следующим образом: макет виртуального адресного пространства

Как показано на диаграмме выше, XV6 специально создает виртуальное адресное пространство процесса, так что виртуальные адреса 2–4 ГБ отображаются в 0 в физические адреса PHYSTOP (соответственно). Как поясняется в официальном комментарии XV6:

Xv6 включает в себя все сопоставления, необходимые для запуска ядра в таблице страниц каждого процесса; все эти отображения появляются над KERNBASE. Он отображает виртуальные адреса KERNBASE: KERNBASE + PHYSTOP до 0: PHYSTOP.

Мотивация для этого решения также указана:

Одной из причин этого сопоставления является то, что Ядро может использовать свои собственные инструкции и данные. Другая причина в том, что ядро ​​иногда должен быть в состоянии написать данную страницу физической памяти, например, когда создание страниц таблицы страниц; каждая физическая страница появляется в предсказуемой виртуальной адрес делает это удобным.

Другими словами, поскольку ядро ​​заставило все таблицы страниц отобразить 2 ГБ виртуальных на 0 физических (и вплоть до PHYSTOP), мы можем легко найти физический адрес виртуального адреса, который превышает 2 ГБ. Например: физический адрес виртуального адреса 0x10001000 может быть легко найден: это 0x00001000, мы просто вычитаем 2 ГБ, потому что именно так мы и отобразили его.

Этот «обходной путь» может помочь ядру легко выполнить преобразование, например, для построения и манипулирования таблицами страниц (где необходимо вычислить физический адрес и записать в память).

Конечно, указанный выше «обходной путь» не является бесплатным, поскольку это заставляет нас тратить драгоценное виртуальное адресное пространство (2 ГБ), поскольку теперь каждый физический адрес имеет по крайней мере уже 1 виртуальный адрес. даже если мы никогда не будем использовать это. что оставляет реальный процесс только 2 ГБ, оставленных от всего виртуального адреса (это всего 4 ГБ, потому что мы используем 32-разрядные для подсчета адресов). Это также было объяснено в официальном комментарии XV6:

Недостаток этой схемы в том, что xv6 не может сделать использование более 2 ГБ физической памяти

Я рекомендую вам прочитать больше об этом в комментариях XV6 под заголовком «Обработка адресного пространства». XV6 Комментарий

...