OSDev

Не отыскал ответа в документации.

Согласно документации, в режиме x64 (AMD64, IA-32e) Interrupt gate имеет размер 16 байт. Всего их может быть 256. Помещаются они обычно в начале памяти, с адреса 0, то есть адрес gate'а удобно узнавать, умножая номер вектора прерывания на 16.

Простые вычисления показывают, что необходимо 4 КиБ памяти для хранения всех gate'ов. Это адреса с 0x0000 до 0x0FFF. Теперь смотрим в карту памяти и видим, что адреса
с 0x0400 до 0x04FF занимает BDA (BIOS data area).

Так вот, неужели из-за этого мне придётся делать одну из следующих вещей? -

• отказывать от всех 256 прерываний и делать только 64,
• поместить gate'ы в другое место, не в начало памяти.

Готов пока пойти на первое, 64 прерывания за глаза хватит, но мне интересно, как в этих случаях поступают люди опытные.

В тех несчастных адресах с 0x0400 до 0x04FF, находятся полезные вещи: буфер клавиатуры, текущий режим и т. д. Есть, наверное, такие люди, кто всё это безжалостно затирает?

1. Никто не затирает их BIOS data area, но в принципе они не нужны.
2.
Это только в реальном режиме они вначале. А так все нормальные программисты кладут в другое место. Дабы не трогать оригинальные вектора BIOSа.
Обычно вектора размещаются там где удобно разработчику те в куче ядра.

Понятно. В принципе, я так и думал, что всю таблицу прерываний складывают в другое место, загружая в IDTR нужный адрес. Но, исходя из эстетических соображений, решил, что кто-то здесь на форуме уже задумывался над нехваткой места в начале адресов, но все-таки решил хранить таблицу там. Так, например, делает разработчик Bare Metal OS, но он нигде не комментирует то обстоятельство, что он стирает занятую память и из его кода не очевидно, что эта память к моменту переопределения прерываний совсем не нужна.

Затирать области данных БИОС нельзя, поскольку тогда компутер может потерять работоспособность. БИОС используется не только явным образом (через вызовы его сервисов), но и неявным, для обработки SMI, и последним нельзя управлять никак.

Управлять можно. Скажем так при включении ACPI управление с SMI переходит в ACPI.

Бред. Никакого "перехода управления" не происходит, появляется лишь возможность стандартным образом сообщать соответствующему коду БИОСа пожелания системы относительно тех или иных вещей. Обработку SMI всё равно осуществляет код БИОСа и только он.

Неа. Источники SMI переводятся на CLI и они становятся клиентами ACPI, а не SMM.
Конечно не все источнике такое могу. И если в SMM мы влезть не можем. То в ACPI запросто. К примеру кнопку выключения питания перепрограммировать.

Вот в том-то и дело, что в SMM влезть возможности нет. А как именно реализована поддержка ACPI на конкретной плате -- дело сугубо разработчиков этой платы и БИОСа. В частности, ничто им не мешает по-прежнему использовать SMM, обрабатывая в нём разные события, в том числе запросы ОС через ACPI на изменение тех или иных режимов и т.д. Поэтому совершенно недопустимо считать, что, переключившись в ACPI, можно рушить структуры данных БИОСа в нижней памяти, о чём я в самом начале и сказал.

Затерать переменные БИОСа себе дороже. С этим то я и не спорю.

Хорошо, не буду затирать данные BIOS, а то мало ли. Но у меня тогда в связи с этим решением возник другой вопрос.

С одной стороны, адреса от 0x0500 гарантированно свободны, это я узнал из карты памяти здесь. С другой стороны, в этой теме на форуме говорится, что фиг там, а не свободное место, поэтому многие начинают писать с 0x0600.

Есть ли у кого точно задокументированная информация по этому поводу, соответствующая правде? Или какие-то доказательства, что в этом диапазоне 0x0500 - 0x05FF BIOS хранит что-то своё?