ARM GICv3·vGIC·ITS interrupt 소스 분석

이 코드는 어떤 문제를 푸나요?

CPU가 IRQ를 처리했다는 사실을 GIC에도 반영해야 다음 알림을 정상적으로 처리할 수 있습니다. 아래는 물리 GICv3의 EOI 함수를 읽는 예입니다. vGIC의 가상 pending과 List Register는 별도 상태이므로 물리 EOI를 곧바로 게스트 EOI와 같은 동작으로 설명하지 않습니다.

읽을 범위: v6.18.37 · drivers/irqchip/irq-gic-v3.c · gic_eoi_irq 719–733행입니다. 아래에 이 범위의 원문과 각 줄의 설명을 실었습니다. 주제 전체의 흐름과 다른 경로는 기존 분석에서 함께 읽으실 수 있습니다.

먼저 알아둘 개념

물리와 가상 인터럽트

호스트가 실제 GIC에서 받은 요청과 게스트에 보여 주는 요청은 다른 상태 기계입니다.

EOImode

우선순위 종료와 비활성화가 한 동작인지 분리되는지를 좌우합니다.

List Register

GIC 가상화 인터페이스가 게스트에게 보여 줄 인터럽트 상태를 담는 자원이며 무한한 큐는 아닙니다.

처음 읽을 때

장치→호스트 GIC→KVM→게스트의 알림 경로를 나누어 설명하십시오.

더 깊이 살펴볼 때

물리 IRQ를 vCPU에 전달할 때 deactivate 책임이 어떻게 달라지는지 EOImode1 경로와 비교하십시오.

그림으로 보는 변화

GIF 재생1단계 · 멈춰 보기2단계 · 멈춰 보기3단계 · 멈춰 보기

1단계 고정

GIF 원본 열기

1. INTID 확보

irq_data에서 물리 하드웨어 번호를 찾습니다.

화살표는 irqdomain 번호 변환의 결과를 사용한다는 의미입니다.

2. 물리 EOI

ICC_EOIR1_EL1을 쓰고 동기화합니다.

이 화살표를 가상 List Register의 직접 갱신으로 읽지 않습니다.

3. 구현별 마무리

필요한 erratum 경로에서 추가 deactivate를 수행합니다.

조건부 작업이며 모든 GIC 경로가 동일하지 않습니다.

gic_eoi_irq를 한 줄씩 읽기

줄 번호는 v6.18.37 원문 기준입니다. 주석·빈 줄을 포함한 함수 전체를 먼저 보고, 그 아래에서 각 줄을 설명합니다.

static void gic_eoi_irq(struct irq_data *d)
{
	write_gicreg(irqd_to_hwirq(d), ICC_EOIR1_EL1);
	isb();

	if (gic_arm64_erratum_2941627_needed(d)) {
		/*
		 * Make sure the GIC stream deactivate packet
		 * issued by ICC_EOIR1_EL1 has completed before
		 * deactivating through GICD_IACTIVER.
		 */
		dsb(sy);
		gic_poke_irq(d, GICD_ICACTIVER);
	}
}

static void gic_eoi_irq(struct irq_data *d)

	write_gicreg(irqd_to_hwirq(d), ICC_EOIR1_EL1);

	isb();

	if (gic_arm64_erratum_2941627_needed(d)) {

		dsb(sy);

		gic_poke_irq(d, GICD_ICACTIVER);

함께 생각해 볼 질문

출처와 읽은 범위

Linux stable v6.18.37 · drivers/irqchip/irq-gic-v3.c

해당 버전 원본 파일 · 기존 코드 분석 · 설명 원고