Maystyle :
Admin : New post
Guestbook
Local
media
Catergories
Recent Articles
Recent Comments
Recent Trackbacks
Calendar
Tag
Archive
Link
Search
 
해당되는 게시물 3건
  지루한 인터럽트 한방에 알아보자 
작성일시 : 2007.11.12 21:03 | 분류 : Windows Server/Kernel | 태그 : IRQL, 인터럽트

 

인터럽트나 Exception이 발생하면 커널은 기존 처리 중 이던 Thread를 커널 스텍에 Trap Frame을 만들어 상태를 처리하고, Trap Handler를 호출하여 해당 Trap을 처리한다. ( 알수 없거나 처리 할 수 없을 경우 KeBugCheckEx를 호출 하고 정지 )

덤프 미 생성시 블러스터 웜/ Disk Array Controller / CPU / Memory / 메인 보드 를 확인 해야 한다.

하드웨어 인터럽트 처리

이전 포스트들을 잘 읽어 봤다면, 용어에 대하여 별도로 설명할 필요는 없을꺼 같다.하드웨어 인터럽트가 발생하면 위와 같은 순서로 처리된다. 또한 CPU는 여러 ISR에 대하여, 개별 적으로 처리가 가능하다.

PIC
http://maystyle.tistory.com/entry/Programmable-Interrupt-Controller
IDT
http://maystyle.tistory.com/entry/IDT-살펴-보기

Windows 에서 인터럽트의 처리 (IRQL)

IRQL에 대해서는 이전 포스트(http://maystyle.tistory.com/entry/IRQL)에서 다뤘다 시피 인터럽트에 대한 처리 우선 순이라 할 수 있다. 즉 더 높은 순위의 인터럽트는 낮은 순위의 인터럽트를 마스크(블럭 시키고 자기가 실행 된다.) 한다. 높은 인터럽트가 발생하면 기 실행 Thread는 저장되고 해당 인터럽트와 연결된 Dispatcher들을 실행 한다.

인터럽트가 발생 > CPU의 IRQL을 높힘 > CPU에서 인터럽트 처리 > CPU의 IRQL을 원상 복귀 시킴
(현재 IRQL 확인 : http://maystyle.tistory.com/entry/현재-CPU의-IRQL을-살펴보자)

중요한건 IRQL을 통해서 PIC와 통신 비용을 줄일 수 있다는 거다. (이 부분은 나만의 유추다) 일단 PIC는 3개의 레지스터를 가지고 인터럽트 프로세스를 진행한다.
IRR - Interrupt Request Register
ISR - Interrupt Service Register
IMR - Interrupt Mase Register
로직은 IRR에서 인터럽트를 요구 할때 IMR와 IRR 값을 비교하여 처리되어야 한다면 ISR 단계로 넘어가게 된다. 그런데, 문제는 HAL에서 IMR을 설정하는 작업이 굉장이 느리다는 것다. (H/W의 인터럽트는 HAL이 IRQL에 Mapping 한다.)그래서 굳이 PIC까지 가서 IMR을 설정하지 않고, IRQL을 만들어 놓고, HAL 단에서 IRQL만 건들여서 우선 순위를 설정하게 된다.

커널 모드 스레드는 자신이 실행하려는 작업에 따라 IRQL을 높히게 된다. 그래서 장치 인터럽트시  커널 및 장치 드라이버는 왠만하면 Passive 수준을 유지하여, 인터럽트를 빠르게 처리하려 한다.

방금 언급한 것 처럼 PIC에서 정의된 IRQ와 IRQL은 다르다. 솔직히 Windows는 IRQ와 별계로 IRQL을 통해 서비스 우선 순위를 결정한다. 그렇다면 어떻게 누가 결정할까? 바로 HAL에서 HalpGetSystemInterruptVector를 호출하여 매핑한다. 이전 포스트를 참고 하자. http://maystyle.tistory.com/entry/인터럽트를-IRQL에-매핑하기

DPC 계층 이상에서 코드가 실행 중일 경우 CPU는 다른 스케줄러를 실행 할 수 없다. 없는데 그런 경우가 생기니깐 장애가 생기는 것이다. DPC는 이전 포스트를 참고 하자. (http://maystyle.tistory.com/entry/DPC-Deferred-Procedure-call)

원문을 참고 하자.
One important restriction  on code running at DPC/dispatch level or above is that it can't wait for an object  if doing so would necessitate the scheduler to select another thread to execute , which is an illegal operation / because the scheduler synchronizes its data structures at DPC/ dispatch level and cannot therefore be invoked to perform a reschedule. Another restriction is that only nonpaged memory can be accessed at IRQL DPC/dispatch level or higher. / This rule is actually a side-effect of the first restriction because attempting to access memory that isn't resident results in a page fault. When a page fault occurs, the memory manager initiates a disk I/O and then needs to wait for the file system driver to read the page in from disk. This wait would in turn require the scheduler to perform a context switch (perhaps to the idle thread if no user thread is waiting to run), thus violating the rule that the scheduler can't be invoked (because the IRQL is still DPC/dispatch level or higher at the time of the disk read). If either of these two restrictions is violated, the system crashes with an IRQL_NOT_LESS_OR_EQUAL crash code. (See Chapter 4 for a thorough discussion of system crashes.) Violating these restrictions is a common bug in device drivers. The Windows Driver Verifier, explained in the section "Driver Verifier" in Chapter 7, has an option you can set to assist in finding this particular type of bug.

본문의 예를 들자면 DPC/디스패치 수준은 무조건 Nonpaged Memory에서 수행되는 것이다.  즉 DPC의 오브젝트들은 메모리에 저장이 되는데, 만약 Page Fault가 발생하게 되면 어떻게 될까? 그렇게 되면 분명 Disk에서 해당 object를 읽어 와야 하고, 또 다시 인터럽트들이 발생하게 된다. 그러면 다시 컨텍스트 전환이 일어나게 되며, 이는 on code running at DPC/dispatch level or above is that it can't wait for an object  를 어기게 된다. 이때 충돌 코드가 IRQL_NOT_LESS_OR_EQUAL이다. 순환 큐가 아닌 이상... 큐에 들어간 DPC는 수행되야 하며, 이에 컨텍스트 스위칭이 일어날 수 없다.

자 마지막으로 인터럽트 개체는 무엇일까?
다음 포스트를 참고하자 (http://maystyle.tistory.com/entry/인터럽트-개체)

Name   Password   Home   Secret   Submit
  현재 CPU의 IRQL을 살펴보자 
작성일시 : 2007.11.12 17:41 | 분류 : Windows Server/Kernel | 태그 : CPU, Debugging, IRQL, PCR

먼저 !irql 을 통해 프로세서의 IRQL 상태를 알 수있다. 위의 경우 lazy irql을 지원하지 않기 때문에 이 필드는 0이다. 아무튼 필자가 가지고 있는 덤프는 위와 같고, 여튼 간에 !pcr을 통해서 IDT에 대한 포인터 현재 실행 스레드와 앞으로 실행할 스래드의 주소를 알 수 있다.

PCR(Process Control Region) 과 PRCB(Processor Control Block)의 구조체는 DDK 의 Ntddk.h에 정의 되어 있다.

Name   Password   Home   Secret   Submit
  IRQL 
작성일시 : 2007.11.06 15:49 | 분류 : Windows Server/Kernel | 태그 : apc, dpc, IRQL

인터럽트의 우선순위는 인터럽트 요구 레벨 (IRQL)의 의해서 정의 된다.

구체적으로 IRQL=5인 인터럽트가 실행 되고 있을 경우 CPU는 IROL이0~5인 인터럽트를 보류시키고 5 인터럽트를 처리한 다음 0으로 내려가 보류중인 인터럽트를 처리한다.

그림 3-3의 High는 모든 인터럽트의 금지 맨 아래의 Passive는 일반 프로그램을 실행하는 상태를 나타내며, 특정 인터럽트는 아니다. Power Fail (전원 장애) 레벨은 사용되지 않으며, Inter-processor interrupt 는 여러 개의 CPU를 탑재한 머신에서 다른 CPU에 셧다운을 요구할 때 쓰인다. Clock은 시스템 클럽에 대한 인터렙트, 'profile'은 Windows 의 각 컴포넌트 (Exe/Dll)안에서 경과된 시간의 비율을 계산하는 프로파일링 실행 중에 실시간 클럭에서 사용하는 인터럽트다.

DPC/dispatch 는 지연 프로시저 호출 (Delayed Procedure Call)과 스레드 전환 (스레드 디스페치)를 위한 소프트웨어 인터럽트다. 지연 프로시저 호출은 I/O 접근 완료 통지 처럼 곧바로 실행하지 않아도 되는 처리를 Windows에서 실행 할 때 쓰인다. 'APC'는 비동기 프로시저 호출을 하기 위한 소프트웨어 인터럽트다 이는 특정 스레드의 컨텍스트로 함수를 실행하기위해 이용한다.

DPC와 APC는 인터럽트를 처리할 때 중요한 역활을 수행한다.인터럽트를 제대로 처리하는데 시간이 걸릴 경우 인터럽트 처리기 안에서 모든 처리를 한다면 그 사이 다른 인터럽트를 처리하지 못할 가능성이 있다. 그래서 곧바로 실행해야 하는 처리만 핸들러 안에서 실행하고, 나머지 처리는 DPC를 이용해 다음에 실행하도록 한다. DPC의 IRQL은 Passive 보다 상위이므로 다른 인터럽트 처리가 모두 끝난 후에 실행될 것을 보장해 준다.

마찬가지로 어플리케이션이 준비한 버퍼에 데이터를 써넣는 처리에서는 그 프로세스의 가상 주소 공간에 접근할 수 있어야 한다. 이런 경우 APC를 이용해 그 프로세스의 스레드로 데이터를 써 넣을 수 있도록 한다.

출처 : API로 배우는 Windows 구조와 원리

Name   Password   Home   Secret   Submit