[멀티 프로세서] I/O APIC

글의 참고

- MultiProcessor Specification 1.4

- 64-ia-32-architectures-software-developer-vol-3a-part-1-manual.pdf [Order Number: 253668-060US]

- 82093AA I/O ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER

- https://people.freebsd.org/~fsmp/SMP/papers/apicsubsystem.txt

---

글의 전제

- 밑줄로 작성된 글은 강조 표시를 의미한다.

- 그림 출처는 항시 그림 아래에 표시했다.

---

글의 내용

: Local APIC의 데이터 시트를 찾아봤지만, `MultiProcessor Specification 1.4`과 `64-ia-32-architectures-software-developer-vol-3a-part-1-manual.pdf [Order Number: 253668-060US]` 문서를 제외하고 별도의 데이터 시트를 찾지 못했다. 그런데, I/O APIC는 Local APIC는 다르게 별도의 데이터 시트가 존재한다. 일단 모델명이 `82093`이다. 이게 별도의 데이터 시트가 존재하는 이유는 프로세서 온 칩이 아니라서 그렇다. 예를 들어, `MultiProcessor Specification 1.4` 에서 Local APIC는 2가지 아키텍처로 구분된다.

0" Discrete APIC Configurations
1" Integrated APIC Configurations

: 작아서 안 보일 수도 있지만, `Discrete` 구조에서 Local APIC는 프로세서 온 칩이 아니다. 별도의 칩으로 나와있다. 그러나, `Integrated` 구조에서는 Local APIC가 프로세서 온 칩으로 되어있다. 그리고, `Discrete` 구조에서는 Local APIC를 `82489DX`라는 모델명이 존재한다. 그러나, LAPIC는 애초에 별도의 문서를 찾기조차 쉽지 않다. 거의 대부분 intel 칩셋 문서에서 같이 배포된다. LAPIC가 `Integrated` 구조에서는 프로세서 내부로 들어가면서 모델명이 사라졌다. 현재의 인텔 프로세서 구조는 `Integrated` 구조만을 채택하고 있는것으로 알고 있다.

: 정리하면, I/O APIC 프로세서 외부로 빠져있기 때문에 별도의 데이터 시트가 존재한다. 그러나, Local APIC는 프로세서 온 칩이라서 프로세서 데이터 시트를 봐야 해당 칩에 대한 정보를 알 수가 있다. 여기서는 `82093AA` 문서를 참고한다.

 

: APIC에서 가장 주목할 만한 부분은 `분산 CPU`다. 즉, PIC는 싱글 프로세서 기반이라서 하나의 CPU에게로만 인터럽트를 포워딩한다. 그런데, APIC 구조는 별도의 APIC 버스 구조를 채택해서 여러 CPU에게 인터럽트를 분산시킬 수 있도록 한다. 각 CPU는 `Local APIC`를 가지고 있으며, 마더 보드상에는 최소 하나의 IO APIC가 존재한다.

 

: 인터럽트를 여러 CPU에게 분산하다보면,  프로세서끼리 인터럽트를 주고 받거나, 모든 CPU가 동일한 인터럽트를 받거나, 특정 CPU만 특정 인터럽트를 받을 수 있는 구조가 되어야 한다. 이 때, 프로세서끼리 인터럽트를 주고 받을 수 있게 하기 위해 인텔은 `IPI(Inter-Processor Interrupt)`를 설계했다. `IPI`는 인터럽트라기 보다는 인터럽트 메세지를 다른 프로세서에게 직접 전달하거나, 나를 포함한 모든 프로세서들에게 브로드 캐스팅도 가능하다.

 

: APIC가 도입된 시스템에서 가장 중요한 부분은 인터럽트를 분산시키는 것이다. 일반적으로 I/O APIC가 외부 인터럽트를 받으면, 해당 인터럽트를 가장 잘 처리할 거 같은 CPU에게로 전달한다. `가장 잘 처리할 것 같은` 은 어떤 의미가 포함되어 있을까? FreeBSD에서 IO APIC 서브 시스템이 도입되었을 때, 도입한 방식을 알아보자.

 

: FreeBSD는 현재 `락`을 잡고 있는 CPU에게 인터럽트를 전달한다. 위에서 `가장 잘 처리할 것 같은` CPU 라는 것이 바로 `락`을 잡은 CPU를 의미한다. 왜 락을 잡은 CPU가 인터럽트를 가장 잘 처리할 수 있다는 것일까? 예를 들어, CPU1과 CPU2가 있다고 치자. CPU1이 열심히 자기 일을 하던 도중 A 라는 리소스의 `락`을 얻게 됬다. 그렇게, `A`를 처리하던 도중에 CPU2도 `A` 리소스를 얻기 위해 크리티컬 섹션에 진입을 시도했다. 여기서 CPU2는 `A`의 락을 얻기 위해 `busy-spin`을 하게 된다. 결국, 일을 계속 처리할 수 있는 건 CPU1 밖에 없다. 앞에 락이 어떤 락이건 종류는 상관없다. 락을 갖지 못한 CPU는 어차피 `busy-spin`의 예비 대상일 뿐이다. 현재 락을 잡고 있는 CPU만 의미가 있다. 그런데, 만약 2개의 CPU가 각각 A, B 리소스에 대한 락을 갖고 있는 경우는 어떻게 할까? 그건 글에 나와있지 않다. 

 

: `락`을 잡고 있는 CPU에게 인터럽트를 전달하기 위해서는 어떻게 해야 할까? 먼저 모든 `Task Priority Register(TPR)`을  

 

왜? 왜냐면, 저 시점에 다른 CPU 들이 해당 `락`을 잡기 위해 

 

 

- IO 리다이렉션 테이블

: 

There are 24 I/O Redirection Table entry registers. Each register is a dedicated entry for each interrupt input signal. Unlike IRQ pins of the 8259A, the notion of interrupt priority is completely unrelated to the position of the physical interrupt input signal on the APIC. Instead, software determines the vector (and therefore the priority) for each corresponding interrupt input signal. For each interrupt signal, the operating system can also specify the signal polarity (low active or high active), whether the interrupt is signaled as edges or levels, as well as the destination and delivery mode of the interrupt. The information in the redirection table is used to translate the corresponding interrupt pin information into an inter-APIC message.

 

- 블락 다이어그램

:

 

 

- 레지스터

: