OSDev

Под таблицей страниц я понимаю область, в которой отображаются (по мере надобности) все таблицы страниц в терминологии Интел (я их называю транс-страницами). Думаю, автор топика тоже не всегда использовал термин "таблица страниц" для обозначения транс-страницы (иначе что могли бы означать слова "лучше держать всю таблицу страниц отображенной", ведь отдельно взятая транс-страница не может отображаться частично). Каталогом я называю то же самое, что и Интел. Хотя у меня каталог одновременно является и транс-страницей, отвечающей за отображение всей 4-мегабайтной таблицы страниц, т.к. я использую рекурсивное отображение каталога (один из входов каталога указывает на сам каталог).

Да, все правильно, "лучше держать всю таблицу страниц отображенной" следует читать "лучше держать все таблицы страниц и директории отображенными". В x86_64 (или IA32e) каталог страниц имеет больше уровней, это вызывает проблемы. Вот у меня адресное пространство:

Еще вопрос: вот есть у меня такое адресное пространство, как сделать еще одно? Сделать нужную иерархию в резерве страниц, а потом только cr3 менять? Большой резерв нужен... Или есть получше способ?

Извините за отступы, в этом редакторе их не выставить

В общем-то да, куда деваться. Большой резерв не нужен, сначала создаём только минимальный набор таблиц, потом переключаемся на новое ВАП и догружаем остальное.

Какие проблемы?

Страницы, использованные для создания нового ВАП тоже нужно мапить на это ВАП, а для этого нужны... страницы.


Проблемы скорее только в голове, нужны 4 страницы, чтобы мапить физ. страницу на V_AS_ROOT_TABLE, потом еще 2 для V_AS_D1_TABLE, потом еще для V_AS_D0_TABLE, и наконец для V_AS_PE_TABLE и это чтобы получить 2Мб адресов в новом ВАП. Я правильно понимаю?

Сначала используются только страницы ядра, а это одни и те же страницы для всех задач. Важно лишь, чтобы был отдельный каталог страниц, всё остальное можно навесить потом.

Не понял. Himik все верно сказал. Дополнительный расход (как по памяти, так и по пространству) минимальный.

Наверняка тоже можно какие-нибудь рекурсивные связи наладить (это удобно и экономит память). Я в этом направлении еще не работал, у меня даже PAE нет. Но можно поразмыслить.

Вы предлагали отображать таблицы на фиксированные адреса в каждом ВАП для определения физического адреса по виртуальному. Сначала сделать где-нибудь (в адресах ядра) новое ВАП, а потом уже отображать его таблицы на фиксированные адреса?

Нет, после создания нового ВАП нужно сразу переключиться на него перегрузив cr3, и далее работать как с обычной памятью.
Перед этим создаём 4 страницы под каталоги в текущем ВАП и связываем их между собой физическими адресами.

Когда ты только начинаешь готовить ВАП для нового процесса, ты используешь специальный участок небольшого размера в пространстве текущего процесса (т.к. по "фиксированному" адресу находится таблица, относящаяся к тек. процессу). Когда при конструировании ты дойдешь до того этапа, при котором новый процесс уже способен выполняться в созданном ВАП, ты можешь его запустить, чтобы он сам завершил конструирование.

В этом посте я недавно вкратце описывал порядок создания нового ВАП. Вообще же я использую глобальные стеки ядра, поэтому мне достаточно в родительском процессе подготовить лишь страницу-каталог для нового процесса (проинициализировать все его глобальные входы).