OSDev

Перейду сразу к телу.

Задача : переход из защищенного режима в защищенный режим с страничной памятью.
Решение: хакаем уже сформированную в долгих мучениях таблицу страниц таким образом, чтобы у страницы в которой находится код перехода, виртуальный и физический адрес были одинаковы -> пинаем CR0 -> делаем прыжок на нормальные виртуальные адреса кода -> откатываем хак из таблицы страниц.

Вопрос: есть ли более человечные методы перехода к страничной памяти? Ибо в рот мне ноги такую магию с памятью.

Не совсем понял, что именно тебя не устраивает во включении пэйджинга? Идентичное отображение переходного кода - аппаратное требование - реализуется элементарно. Рекурсивное отображение каталога позволяет максимально упростить включение и дальнейшее управление пэйджингом. Для включения достаточно проинициализировать 2 дополнительные страницы (при 32-разрядной адресации) - каталог и таблица страниц для переходного кода.

Если честно, то хотелось чего-то похожего на переход в защищенный режим (поменяли бит прыгнули на новый адресс и вот как раз в этот момент магическим образом и начали работать фичи ЗР).

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

Я код инициализации (условно говоря "загрузчик") выделяю в самостоятельную сущность с отдельным страничным контекстом. У загрузчика нестандартная карта памяти, т.к. память в основном состоит из прямого отображения на физическую. В контексте загрузчика делается полнная инициализация ядра, потом строится новая задача и делается переключение задачи.

Таже фигня. Загрузчит получает управление от бутстрап загрузчика работает в защищенном режиме, может находится в памяти где угодно. Размещает в нужном месте ядро и задачу, переходит в страничный режим, формирует адрессное пространство задачи инициализирует ядро и задачу, передает управление задаче.

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

Какая карта памяти? Карта физической памяти? Или разметка ВАП? Если речь о физической памяти, то она вся доступна за исключением той области, куда было загружено твое ядро изначально. Если речь о ВАП, то для включения пэйджинга достаточно небольшого набора страниц и небольшого количества отображенных страниц. Как я уже сказал, достаточно двух страниц - таблицы для идентичного отображения и каталога/таблицы для управления 4-мегабайтной таблицей страниц процесса. К этому можно добавить еще одну страницу - для отображения рабочих структур менеджера физической памяти. В таком виде это соответствует моему минимальному набору. При включении пэйджинга может быть отображено и значительно больше памяти. Но это уже совершенно непринципиальные вещи. Варьируется от версии к версии. В минимальном наборе я использую идентичное отображение в начале ВАП (отображаю только первые 640 кб, т.к. образ ядра, включая инициализационные секции, изначально загружается в базовую память), таблицу страниц процесса отображаю в конце ВАП, а таблицу свободных страниц для менеджера физической памяти (она выравнивается на 4-мегабайтную границу) - в том месте, где будет находиться ядро постоянно. В более сложном варианте до включения пэйджинга я отображаю не только таблицу свободных страниц для менеджера физической памяти, но и всю память для области ядра, которая уже никогда в пул свободных страниц возвращаться не будет - это память для секций symbols (code & data) и bss. Для области, резервируемой ядром (секция rma), я сразу инициализирую только таблицы страниц, а конечные страницы подключаю уже потом по мере необходимости. Я использую ядро с фиксированными адресами: инициализационные секции компилируются по "низким" адресам (в них физический, виртуальный линейный и внутрисегментный адреса совпадают); секции symbols, bss и rma компилируются по "высоким" адресам. Инициализационный код защищенного режима сразу после включения пэйджинга (или после включения и отображения памяти для области ядра) копирует секцию symbols по "высоким" адресам на то место в ВАП, где будет постоянно размещаться ядро. Потом еще долго выполняется инициализация в рамках инициализационной секции, хотя отдельные подпрограммы и данные из symbols уже можно использовать (т.к. они уже находятся на своем "законном" месте), а также использовать bss и rma. Затем передается управление по "высоким" адресам, после чего таблица страниц, используемая для идентичного отображения, отцепляется - с этого момента вся базовая память (кроме первой физ. страницы) переходит под управление менеджера физической памяти (он ее использует при запросах на выделение непрерывных областей физической памяти). Теперь ВАП становится похоже на ВАП обычного процесса (в первые 4 мега у меня память не отображается вообще) перед подключением к нему исполняемого файла. Первичная задача у меня запускается не совсем обычным способом. Инициализационный код просто переходит в основной поток первичной задачи, когда создаются соответствующие структуры для потока и процесса.