인터럽트를 IRQL에 매핑하기

IRQL 로 인터럽트를 맵핑하는 방식은 원문을 인용하도록 하겠다.

IRQL levels aren't the same as the interrupt requests (IRQs) defined by interrupt controllers—the architectures on which Windows runs don't implement the concept of IRQLs in hardware. So how does Windows determine what IRQL to assign to an interrupt? The answer lies in the HAL. In Windows, a type of device driver called a bus driver determines the presence of devices on its bus (PCI, USB, and so on) and what interrupts can be assigned to a device. The bus driver reports this information to the Plug and Play manager, which decides, after taking into account the acceptable interrupt assignments for all other devices, which interrupt will be assigned to each device. Then it calls the HAL function HalpGetSystemInterruptVector, which maps interrupts to IRQLs. (출처 : Windows internals 4th edition)

IRQL 수준들은 인터럽트 컨트롤러 (PIC)에 의해 정의된 IRQ를 사용하지 않고, 버스드라이버가 HAL의 함수 HalpGetSystemInterruptVector를 호출하여 인터럽트들을 IRQL에 매핑한다.

또한 적당한 IRQL에 대한 할당은 PnP 관리자가 결정하게 된다.

HAL은 정방향 변환을 수행하므로, 인터럽트 벡터의 IRQL은 27에서 인터럽트 벡터를 빼서 계산된다. (0~27까지 IRQL에서 할당 받을 수 있다고 되어 있다. 물론 추측이다.)즉 장치가 인터럽트 벡터 5를 사용한다면 ISR은 IRQL 22에서 실행된다. 이전 포스트( http://maystyle.tistory.com/entry/IDT-살펴-보기 )에서 본 것 처럼 IDT의 인덱스를 통해서 인터럽트를 수행한다.

매핑되지 APIC의 경우 200여개 이상의 인터럽트 백터가 존제하게 되는데 이경우 라운드 로빈 방식으로 인터럽트 벡터들을 할당한다. 그리고 x64및 IA64 시스템들의 경우 HAL에서 16으로 벡터를 나누어 주어진 IRQ에 대한 IRQL을 계산한다.

이전 포스트 ( http://maystyle.tistory.com/entry/IRQL ) 에서 해당 IRQL의 각 레벨에 대해 다시 한번 애기하도록 하겠다.

. 커널은 KeBugCheckEx로 시스템을 멈추고 인터럽트를 마스킹할때만 High 수준을 사용한다.

. IPI 는 다른 프로세서가 특정 스레드를 실행하도록 스케줄링 하기 위해 DISPATCH_LEVEL 인터럽트를  대기열에 넣는 작업 및 프로세서의 변환 참조 버퍼 (TLB) 갱신 또는, 시스템 종료, 시스템 충돌과 같은 동작을 수행하도록 요청하기 위해 사용된다.