GIC 인터럽트의 번호와 처리 완료를 따라가 봅니다

같은 SGI라도 GICv2와 GICv3의 전송 방식이 다릅니다

SGI는 Software Generated Interrupt로, 소프트웨어가 다른 CPU에 알림을 보낼 때 사용하는 인터럽트입니다. “SGI를 발생시키려면 GICD_SGIR에 쓴다”는 설명을 GICv3의 일반적인 system register 경로에 그대로 적용하면 안 됩니다. GICv2와 호환 동작의 설명인지, GICv3 affinity routing을 사용하는 설명인지 먼저 구분해야 합니다.

이 글은 GICv3의 system register interface와 affinity routing이 준비된 Non-secure Group 1 환경을 설명합니다. Non-secure는 Linux가 실행되는 보안 상태이며, Group 1은 GIC의 인터럽트 그룹입니다. EL0 사용자 프로그램이 아래 MSR을 직접 실행할 수 있다는 뜻은 아닙니다. 접근 권한과 상위 EL의 설정이 맞아야 합니다. GICv2 IPI 전송 GICv3 gic_send_sgi gic_write_sgi1r

대상 CPU와 SGI 번호를 값 하나에 담아 봅니다

설명용으로 Linux 논리 CPU 5의 affinity가 0.0.2.2라고 정하겠습니다. 네 숫자는 Aff3.Aff2.Aff1.Aff0이며 실제 장치의 CPU 배치는 firmware와 커널의 CPU mapping으로 확인해야 합니다. CPU 번호 5를 그대로 TargetList의 5번 비트에 넣지 않습니다. 여기서는 SGI INTID 3을 그 CPU 한 곳으로 보냅니다.

/* 위의 affinity와 SGI 번호로 만든 설명용 값입니다. */
value = (3ULL << 24) | (2ULL << 16) | (1ULL << 2);
/* value = 0x0000000003020004 */

ULL은 C에서 unsigned long long 정수 상수를 뜻하고, |는 비트별 OR 연산입니다. 24와 16은 이 register에서 각각 SGI 번호와 Aff1 필드가 시작하는 비트 위치입니다. 1 << 2는 CPU 수를 4로 정하는 계산이 아니라 2번 비트 하나를 켜는 계산입니다. Linux는 gic_cpu_to_affinity에서 논리 CPU를 변환한 뒤, 같은 전송에 묶을 수 있는 대상들을 gic_compute_target_list로 모읍니다. TargetList가 16비트라는 이유로 시스템 전체 CPU 수가 16개 이하라는 결론을 내리면 안 됩니다. SGI1R 필드의 비트 위치 CPU mapping·TargetList 계산

명령마다 x0와 알림 상태가 어떻게 바뀝니까?

아래는 위 숫자를 명령으로 준비하는 예입니다. 초기 x0는 앞선 코드가 남긴 값이며 무엇인지 몰라도 첫 MOVZ 뒤의 값은 정해집니다. 전송 전에 공유 자료가 이미 준비되어 있고, 대상 CPU와 SGI 설정이 유효하다고 가정합니다. 실제 Linux에서 임의의 SGI 번호를 골라 실행할 예제가 아니라 값과 순서를 읽기 위한 코드입니다.

movz x0, #0x0004
movk x0, #0x0302, lsl #16
dsb ishst
msr ICC_SGI1R_EL1, x0
isb

온라인 CPU에 보내는 SGI와 PSCI CPU_ON으로 보조 CPU의 시작 주소를 넘기는 과정은 다릅니다. CPU가 아직 커널 초기화를 마치지 않았다면 SGI 값만 맞춘다고 정상 IPI handler가 생기지 않습니다. CPU 시작·idle 복귀·task wakeup의 차이는 기존 CPU 시작 글에서 이어서 보실 수 있습니다.

DT의 6, GIC의 38, Linux IRQ 52가 같은 사건일 수 있습니다

장치가 GIC에 직접 연결된 SPI를 사용하고, interrupt-parent가 해당 GIC node인 예를 보겠습니다. 숫자 52는 설명을 위해 가정한 Linux 할당 결과이며 실제 부팅에서는 달라질 수 있습니다.

interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;

GIC_SPI와 IRQ_TYPE_LEVEL_HIGH는 CPU가 런타임에 읽는 문자열 이름이 아닙니다. 필요한 DT header가 포함된 DTS에서 전처리되는 상수입니다. 런타임의 Linux가 DTB cell을 읽어 번호와 trigger를 해석하는 단계와 나누어 봅니다. PPI는 이 경로에서 16을 더하며, ACPI GSI에는 같은 DT offset 규칙을 기계적으로 적용하지 않습니다. GICv3 DT cell 규칙 DT의 GIC 종류 상수 trigger 상수 gic_irq_domain_translate·gic_irq_domain_map

따라서 예전 표의 “1024~8191은 모두 reserved”라는 설명을 현재 지원 범위 전체에 적용하면 안 됩니다. v6.18.37의 __get_intid_range와 DT binding은 Extended PPI/SPI를 따로 구분합니다. 반대로 표에 범위가 있다고 모든 장치가 그 확장을 갖는 것도 아닙니다. 현재 driver의 INTID 범위 판정

IRQ 진입, acknowledge, 원인 제거, EOI는 다릅니다

CPU가 IRQ 예외에 진입한 것만으로 어떤 INTID인지 읽은 것은 아닙니다. GIC의 IAR, Interrupt Acknowledge Register를 읽어 번호를 얻으면서 acknowledge합니다. 일반적인 SPI에서는 이때 active 상태가 생깁니다. 디버거에서 IAR을 임의로 읽으면 상태를 바꿀 수 있으므로 단순 조회용 register처럼 취급하면 안 됩니다.

EOI는 End Of Interrupt의 약어입니다. EOImode=0은 EOIR에서 priority drop과 deactivate를 함께 하고, EOImode=1은 분리합니다. priority drop은 CPU interface의 running priority를 내려놓는 동작이며 장치의 프로그램 작업을 끝내는 명령이 아닙니다. 또한 SPI의 shared는 모든 CPU가 한 사건을 동시에 처리한다는 뜻이 아닙니다. 지정한 한 PE 또는 지원되는 1-of-N 정책으로 선택된 한 PE가 대상이 됩니다. DAI 0492B · SPI routing·acknowledge·EOImode

이 구분 때문에 “EOI는 언제나 handler 맨 뒤의 한 번짜리 완료 작업”이라고 설명하면 실제 Linux 흐름을 놓칩니다. GIC가 priority를 내려놓아도 CPU의 interrupt mask와 다른 실행 조건까지 모두 풀린 것은 아닙니다. 또 level source가 남아 있으면 deactivate 이후에도 pending 상태가 남거나 다시 전달될 수 있습니다. __gic_handle_irq·gic_complete_ack·gic_eoimode1_eoi_irq IAR·DIR 접근

물리 LPI는 일반 SPI처럼 active와 active+pending 상태를 사용하지 않습니다. Linux의 분리 모드 callback도 LPI에는 DIR을 통한 deactivate를 하지 않습니다. SGI 역시 후속 기능으로 active 상태를 쓰지 않는 구성이 있으므로 “모든 인터럽트는 네 상태를 거친다”는 일반화는 피해야 합니다. 이 버전의 gic_dist_init은 지원되는 경우 nASSGI 기능을 활성화합니다. nASSGI는 SGI의 active 상태를 사용하지 않는 기능입니다. LPI deactivate 제외·nASSGI 설정 DAI 0492B · LPI 상태의 예외

MSI의 EventID와 LPI INTID도 별개의 번호입니다

ITS, Interrupt Translation Service를 사용하는 물리 LPI 예를 보겠습니다. 장치의 DeviceID는 0x120, 전송한 EventID는 5, 미리 설정한 변환 결과는 LPI INTID 8197이라고 정했습니다. 여기서 8197은 예제의 매핑 값입니다. 8192+EventID라는 고정 계산 규칙을 뜻하지 않습니다.

Linux의 its_irq_compose_msi_msg는 EventID를 MSI data에 넣습니다. 별도로 its_build_mapti_cmd는 DeviceID, EventID, physical INTID, collection을 명령에 담습니다. MSI를 보내는 동작과 그 전에 대응 관계를 설정하는 MAPTI 명령은 다릅니다. MAPTI는 ITS의 Interrupt Translation Table에 사용할 대응을 설정하는 명령입니다. MSI 메시지 구성·MAPTI 인코딩

LPI가 항상 ITS를 거쳐야 한다고 일반화하지는 않습니다. Arm의 이 입문 규격은 ITS 지원을 선택 사항으로 설명하며, Redistributor에 직접 보내는 구성도 다룹니다. 여기서는 Linux의 ITS 경로를 예로 들었습니다. LPI 지원 여부와 선택한 전달 경로는 실제 구현에서 확인해야 합니다. DAI 0492B · 6절의 선택적 ITS 지원

게스트의 인터럽트 번호는 호스트 번호와 분리합니다

가상 머신에는 자신의 GIC와 CPU topology가 있습니다. 게스트가 쓰는 affinity는 게스트 vCPU를 식별합니다. 같은 숫자의 호스트 물리 CPU를 직접 선택하는 값으로 읽으면 안 됩니다. 이 절은 일반적인 GICv3 VGIC 소프트웨어 SGI 처리 경로를 다루며, GICv4 계열의 직접 전달 최적화는 별도로 봅니다.

LR은 List Register의 약어입니다. 여기서 어셈블리의 link register x30을 뜻하지 않습니다. vgic_v3_populate_lr는 irq->intid와 상태로 값을 구성합니다. 물리 IRQ와 연결하는 hardware-backed 경로에서는 hwintid도 별도 필드로 사용합니다. 가상 INTID와 물리 INTID가 다른 값으로 관리된다는 점을 코드에서도 확인할 수 있습니다. 가상 SGI 대상 선택 LR 구성·상태 회수

v6.18.37의 virtio_mmio.c는 platform_get_irq로 얻은 번호를 request_irq에 넘깁니다. virtio_pci_common.c에는 별도의 MSI-X 경로가 있습니다. VGIC API 문서는 사용자 공간 장치가 VM의 interrupt controller로 주입하도록 정하며, 가상 ITS 지원은 별도 선택 사항입니다. virtio-mmio IRQ 등록 virtio-pci MSI-X VGIC의 VM 내 역할 가상 ITS의 지원 조건

irqfd는 eventfd의 알림을 KVM의 guest interrupt 주입에 연결하는 인터페이스입니다. eventfd는 알림을 주고받는 Linux 파일 descriptor이며, irqfd의 gsi는 KVM에 설정한 routing entry를 찾는 값입니다. arm64에서 해당 entry가 irqchip 경로이면 pin+32가 가상 SPI INTID이고, MSI 경로이면 메시지와 DeviceID를 가상 ITS가 LPI로 번역합니다. 따라서 irqfd를 썼다는 사실만으로 SPI인지 LPI인지 정해지지 않습니다. 예를 들어 gsi 12의 entry가 irqchip pin 6에 연결되어 있다면 가상 SPI는 38입니다. 12·6·38은 역할이 서로 다른 예제 값입니다. KVM_IRQFD의 arm64 routing 규칙

로그의 숫자를 연결해서 읽는 순서

기존 GIC 상세 글은 Distributor·Redistributor·CPU interface와 Linux dispatch를 나누어 설명합니다. 이 글은 그 구조에 숫자를 대입하고, 한 줄의 SGI 명령과 acknowledge·EOI가 바꾸는 상태를 보충한 설명입니다. 예제는 실제 장치에 실행하지 않았으며, 커널 경로는 Linux v6.18.37 소스와 대조했습니다.

이어서 읽기

• CPU 시작 요청과 IPI의 차이
• 게스트 예외와 KVM 반환의 경계
• CPU·장치의 저장 순서와 barrier
• blog/hardware/interrupt/gic-intid-state-trigger.html
• blog/hardware/interrupt/gic-cpu-interface-icc.html
• blog/hardware/interrupt/gic-its-lpi-msi.html
• blog/hardware/interrupt/gic-linux-irqdomain-dispatch.html