← Interrupt 상세 목차DUJINLABS.COM

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를 훔칠 수 있습니다.

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

공개되지 않은 vendor register나 integration별 offset을 추측해서 채우지 않았습니다. 아래 제조사 자료, architecture 문서와 Linux v6.18.37 원본에서 다시 확인할 수 있는 범위만 사용했습니다.