← Interrupt 상세 목차

Hardware · Interrupt detailed manual 04 · Linux v6.18.37

4. claim/complete의 destructive read와 완료 순서를 검증한다

claim read는 최고 우선순위 source ID를 반환하며 pending을 원자적으로 소비합니다. handler가 device 원인을 처리한 뒤 같은 ID를 complete write하고 MMIO ordering을 지켜야 합니다.

상세 표
2
검증 행
14
절차
4 checkpoints
기준
RISC-V PLIC · AIA · Linux v6.18.37

CHAPTER 04

4. claim/complete의 destructive read와 완료 순서를 검증한다

claim read는 최고 우선순위 source ID를 반환하며 pending을 원자적으로 소비합니다. handler가 device 원인을 처리한 뒤 같은 ID를 complete write하고 MMIO ordering을 지켜야 합니다.

claim side effect

read는 단순 조회가 아니라 request를 claim합니다.

0 반환

현재 context에 전달 가능한 pending source가 없음을 뜻합니다.

complete

claim한 ID를 같은 context completion에 write해 gateway를 재활성화합니다.

ordering

device status clear가 complete보다 늦게 보이면 level source가 즉시 재요청될 수 있습니다.

레지스터·번호·소유권 대조

항목소유자값의 의미정상 증거오류 해석
claim/completePLIC contexttop ID read/ID writeclaim ID와 complete ID 동일잘못된 context/ID
device status/ackperipheralsource 원인 clearcomplete 전 deassertstorm
pendingPLIC globalclaim 전 set, 후 clear/변화상태 수명 설명 가능debug read가 claim 소비
thresholdcontextclaim 후보 필터handler policy와 일치nested 처리 차단
MMIO barrierCPU/busdevice clear→complete 순서stress에서도 재진입 없음posted write ordering

오류가 발생한 단계 확인

증상직전 통과우선 확인반증 시험판정
debug read 후 IRQ 사라짐pending 있었음claim side effect관찰 code 제거debugger가 소비
complete했는데 재진입handler 실행device clear visibilityreadback/barrier 추가 비교ordering/source 유지
complete ID mismatchclaim ID 기록handler 저장/중첩per-hart stack tracestate 보존 오류
claim 0 반복CSR external pendingcontext/threshold같은 주소와 enable 확인잘못된 context
부하에서 특정 source 굶음여러 pendingpriority/tie와 handler loopclaim loop histogram우선순위/처리량
그림 1. 「4. claim/complete의 destructive read와 완료 순서를 검증한다」의 실행 순서왼쪽부터 신호나 데이터를 처리하는 순서를 나타냅니다. 각 단계에서 확인할 항목을 함께 표시했습니다.
01 trap
02 claim read
03 ID validate
04 domain dispatch
05 device ack
06 MMIO barrier/readback
07 complete ID write
08 next claim

실제 검증 절차

순서실행남길 증거판정 목적
1claim/complete ID와 hart/context를 ring buffer에 기록합니다.쌍의 일치완료 검증
2device clear와 complete 사이 timestamp/readback을 남깁니다.ordering 증거storm 분석
3여러 source를 동시에 발생시켜 claim order를 확인합니다.priority/tie 결과arbiter 검증
4handler loop가 종료될 때 마지막 claim 0을 확인합니다.drain 완료남은 pending 판정

주의claim register를 외부 debugger에서 읽지 않습니다. 상태 확인만 하려다가 실제 interrupt를 소비할 수 있습니다.

공개적으로 다시 확인할 수 있는 자료

공개되지 않은 제조사 레지스터나 제품별 오프셋은 추측하지 않았습니다. 아래의 제조사 자료, 아키텍처 문서, Linux v6.18.37 원본으로 확인할 수 있는 내용만 다뤘습니다.