Почему меньше IRQL в 64-разрядной версии, даже если APIC имеет больше строк прерываний?

Поскольку компьютеры x86 переместились с 32-разрядных на 64-разрядные, они также перешли от использования программируемых контроллеров прерываний 8259 с 8 линиями прерываний. (Или два мультиплексированных ПОС для 15 линий прерываний). Затем, если бы вы установили 32-битную Windows для операционной системы, Windows могла бы реализовать 32 программных IRQL (уровни запросов прерываний) с IRQL с 3 по 26 (или около того) зарезервированы для устройств.

Затем появилась платформа x64. Вам нужна машина с APIC, которая имеет 256 строк прерываний, чтобы установить на нее 64-битные Windows. Однако 64-битная Windows реализует только 16 IRQL.

Итак, мой вопрос: кто-нибудь знает, почему 64-битная Windows будет внедрять меньшее количество IRQL, чем его 32-разрядный аналог, даже если в его распоряжении имеется гораздо больше аппаратных прерываний?

7 голосов | спросил Ryan Ries 7 PM00000080000004231 2012, 20:09:42

3 ответа


1

Потому что с системой типа DOS вам нужно IRQ для каждого события и так много уровней IRQ, чтобы события могли маскировать другие события просто. С реальной ОС вы в значительной степени просто нуждаетесь в одном событии, и пусть ядро ​​вычисляет все остальное (на самом деле удобно иметь пару уровней для NMI и в режиме реального времени).

Итак, я предполагаю, что с 64-битной версией и зная, что вы не поддерживаете обратную совместимость с некоторыми приложениями DOS на 386, они воспользовались этой возможностью, чтобы упростить.

ответил Martin Beckett 7 PM00000090000003631 2012, 21:47:36
0

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

Таблица дескрипторов прерываний (IDT) - это замена защищенного режима для таблицы векторов прерываний (IVT). Базовый адрес IDT хранится в регистре CPU и может располагаться почти в любом месте в памяти.

Вы можете просмотреть содержимое IDT, если у вас есть отладчик ядра, используя! idt. Помимо ожидаемых 32 нечетных обработчиков исключений и нескольких устаревших устройств, вы не найдете многого в современном IDT. Я попытаюсь объяснить, почему позже.

Каждое прерывание заставляет CPU войти в режим ядра, поэтому код режима ядра может справиться с ними.

Нулевой уровень запроса прерывания (IRQL) не является уровнем, так как все прерывания разрешены. Код режима пользователя обычно выполняется с нулевым значением IRQL.

Ядро и драйверы используют программные прерывания для выдачи вызовов отложенной процедуры (DPC), расписания потоков и асинхронных вызовов процедур (APC). Отправка DPC /потоков выполняется на IRQL два и APC на уровне один.

Ядро и драйверы всегда стараются держать IRQL как можно более низким. В наши дни процедуры обслуживания прерываний драйверов часто делают чуть больше, чем acknolage прерывания перед вызовом DPC для выполнения любой передачи данных. Таким образом, IRQL можно сбросить с уровня устройства как можно быстрее.

Извините, я сказал, что объясню отсутствие записей IDT, но мне нужно выйти. Сообщения об ошибках с сообщением, MSI-X и x2 локальные APIC являются причиной. Если кто-то заинтересован, спросите

ответил Wheels-of-Fire 6 J000000Thursday17 2017, 11:30:13
-2

Его немного сложнее, я боюсь. Все еще не дошли до конца, но я расскажу то, что знаю. Windows отмечает примечание о том, что IRQL использует его для КАЖДОГО логического процессора в том, что он вызывает блок управления процессором, который представляет собой структуру данных, а не какой-либо регистр. Существует также таблица дескрипторов прерываний с 256 элементами, которые в конечном итоге указывают на прерывание сервисных процедур. Я говорю в конце концов, потому что сначала мы проходим через объект прерывания, который сохраняет примечание о прерываниях, назначенных IRQL, а также диспетчер прерываний. У 32-битных процессоров X86 не было понятия IRQL как такового, но разработчики Windows решили, что у них будет 32 из них. IRQL устройства было решено, взяв его номер вектора и выделив его на 16. Помните, что номер вектора не совпадает с номером вывода IRQ (любой вывод может иметь любой вектор между 32 и 255, потому что первые 32 вектора зарезервированы для исключения). Чтобы выполнить эту работу, Windows должна запрограммировать микросхему PIC для маскировки контактов прерываний, которые ниже уровня, который он записал для CPU. Это было изменено с помощью X64, потому что CPU получил конкретный модельный регистр, который фактически устанавливал CPU на IRQL между 0 и 15. Разработчики окон использовали это для упрощения.

ответил Wheels-of-Fire 6 J000000Thursday17 2017, 01:45:26

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132