Уровни запросов программных прерываний

Контроллеры различают уровни приоритетов прерываний, ОС Windows в то же время ведет свою схему приоритетов прерываний, которая известна как IRQL (Interrupt Request Level). IRQL представляется внутри ядра в виде номеров: 0-31 для x86, 0-15 для x64 и Intel Architecture 64. Больший номер – больший приоритет.

HAL увязывает IRQL с номерами аппаратных прерываний. Слайд 26 – уровни запросов для 32- и 64-разрядных.

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

Замечание: когда ОС снижает уровень приоритета, могут появиться (материализоваться) ранее необработанные прерывания, т.к. уровень был повышен, поэтому они начинают обрабатываться.

Замечание: не надо путать приоритеты уровней прерываний IRQL и приоритеты процесса при планировании потоков. Приоритет потока – атрибут потока. Уровень приоритета IRQL – атрибут источника прерывания.

Примечание: слайд 27 – прерывания от источника с IRQL, превышающей текущий уровень приоритета выполняемого потока прерывает работу процессора, а прерывания от источника с менее низким уровнем маскируются до тех пор, пока поток не получит сниженный IRQL.

Обработчик ловушки может повысить IRQL источника прерываний сам, поэтому вся остальная обработка прерываний откладывается.

Существует понятие «уровень IRQL Passive» - уровень, на который снижаются приоритеты IRQL, чтобы дать возможность обработать все прерывания. Изменение IRQL выполняется в режиме ядра, пользовательские приложения не могут изменять IRQL.

Увязка прерываний с IRQL: стоит помнить, что концепция Windows IRQL не поддерживается аппаратно там, где Windows работает. Поэтому возникает вопрос: какой IRQL установить источнику и исходя из каких данных. Ответ на этот вопрос предоставляет HAL. Он определяет приоритеты устройств на основе драйвера шины. Драйвер шины выделяет каждому устройству прерывания, после чего вызывает функцию HalpGetSystemInterruptVector(), которая увязывает реальные прерываний с IRQL.

Замечание: не во всех версиях HAL выполняется это. Например в однопроцессорных x86 системах IRQL вектора прерывания вычисляется путем вычитания реального номера прерывания из 27-ми.

Замечание: приоритет прерываний, их своевременность и точность во многом определяют эффективность функционирования всей системы. Существуют также так называемые предопределенные IRQL. К ним относятся:

1) IRQL с уровнем HIGH (запрещаются выполняться все прерывания), работает в режиме ядра, при этом прерывания не теряются, а поступают в очередь на обработку.

2) уровень Power Fail – отказ электропитания – блокирует все процессы в случае отказа электропитания.

3) Interprocessor Interrupt – межпроцессорное прерывание – используется при взаимодействии процессоров и запроса на выполнение какой-то операции. Тоже достаточно приоритетное прерывание, которое блокирует все остальные.

4) уровень Clock – используется для управления системными часами, распределением и измерением времени, выделяемого исполняемым потокам.

5) уровень Profile – прерывание, которое блокирует все остальные ниже него, когда включен режим измерения производительности.

6) уровень устройства Devive (1…n) – задает приоритеты прерываний от тех или иных устройств.

7) прерывания обработки отложенных процедур DPC. Этот IRQL предоставляется программным прерыванием. которое генерируется ядром или драйверами устройств.

8) уровень Passive – ничего не блокирует, позволяет все прерывать и выполнять соответствующие обработчики.

Замечание: в ОС Windows на приоритетные уровни накладываются некоторые ограничения. Например, код, выполняемый на уровне DPC и выше не должен ждать освобождения какого-нибудь объекта (ресурса), т.к. в этом случае надо было бы переключить контекст ожидаемого процесса на другой, т.е. перераспределить процессорное время. Это операция запрещенная, т.к. диспетчер процессов работает на уровне DPC и не может быть активирован для перераспределения процессора от одного потока к другому. Следующее ограничение касается того, что на уровне DPC или выше доступна только реальная ОП, не подвергающаяся страничному обмену. Это ограничение также следует из того, чтобы не переключать контекст с одного процесса на другой в случае отсутствия страницы и ее ожидания подкачки в реальную ОП.