Agent skill
interrupt-trace
Use when analyzing low-level interrupt behavior - debugging interrupt handler issues, investigating crashes or triple faults, verifying privilege level transitions, analyzing register corruption between interrupts, or understanding interrupt sequencing and timing issues.
Install this agent skill to your Project
npx add-skill https://github.com/majiayu000/claude-skill-registry/tree/main/skills/development/interrupt-trace-ryanbreen-breenix
SKILL.md
breenix-interrupt-trace
When to Use This Skill
Use this skill when you need to analyze low-level interrupt behavior in Breenix:
- Debugging interrupt handler issues (timer, syscalls, exceptions)
- Investigating unexpected crashes or triple faults
- Verifying privilege level transitions (Ring 0 <-> Ring 3)
- Analyzing register corruption between interrupts
- Understanding interrupt sequencing and timing issues
Overview
This skill captures QEMU's interrupt trace logs and provides systematic analysis of:
- Interrupt vector sequences (what interrupts fired and when)
- CPU register state at each interrupt
- Privilege level transitions
- Anomalies (unexpected exceptions, register corruption, etc.)
Step-by-Step Instructions
Phase 1: Capture Interrupt Trace
-
Set up environment variables:
bashexport BREENIX_QEMU_LOG_PATH=/tmp/breenix-int-trace.log export BREENIX_QEMU_DEBUG_FLAGS="int,cpu_reset,guest_errors" -
Run QEMU with trace enabled:
bashcargo run --release --bin qemu-uefi -- -serial stdio -display none -
Wait for completion or crash (typically 5-10 seconds for boot stages test)
-
Verify trace was captured:
bashls -lh /tmp/breenix-int-trace.log
Phase 2: Parse Interrupt Sequence
Extract the interrupt vector sequence:
grep "v=" /tmp/breenix-int-trace.log | head -100
What to look for:
v=20(0x20 = 32): Timer interrupt - should fire regularlyv=80(0x80 = 128): Syscall interrupt - indicates userspace is making syscallsv=0d(13): General Protection Fault - privilege violation or invalid operationv=0e(14): Page Fault - memory access issuev=08(8): Double Fault - critical error handling another exceptionv=06(6): Invalid Opcode - executing bad instruction
Phase 3: Analyze Privilege Transitions
Check for Ring 0 <-> Ring 3 transitions:
grep "CPL=" /tmp/breenix-int-trace.log | head -50
Expected patterns:
CPL=0: Kernel mode (Ring 0)CPL=3: User mode (Ring 3)- Syscalls should transition:
CPL=3-> interrupt ->CPL=0 - Return from interrupt should transition:
CPL=0-> iret ->CPL=3
Phase 4: Examine Register State
For critical interrupts, examine full register dumps:
# Look at the last 200 lines before a crash
tail -200 /tmp/breenix-int-trace.log
# Or search for specific interrupt vectors
grep -A 10 "v=0d" /tmp/breenix-int-trace.log | head -50
Key registers:
RIP: Instruction pointer - where the interrupt occurredRSP: Stack pointer - check for stack corruptionCR3: Page table base - verify process contextRFL: Flags register - check interrupt enable flag (IF)
Phase 5: Identify Anomalies
Common patterns indicating problems:
-
Unexpected exception cascade:
v=0e (Page Fault) v=0d (GPF) v=08 (Double Fault) v=02 (Triple Fault) -> CPU reset -
Stack pointer corruption:
- RSP outside valid range
- RSP not aligned
- RSP pointing to unmapped memory
-
Missing timer interrupts:
- Long gaps between
v=20events - Could indicate interrupts disabled too long
- Long gaps between
-
Privilege level confusion:
- CPL=3 code accessing kernel memory
- CPL=0 code with user stack pointer
Phase 6: Generate Summary Report
Provide a report with:
-
Interrupt Statistics:
- Total interrupts captured
- Breakdown by vector (timer, syscall, exceptions)
- Frequency of each type
-
Privilege Transitions:
- Number of Ring 3 -> Ring 0 transitions
- Number of Ring 0 -> Ring 3 transitions
- Any stuck in one ring?
-
Anomalies Found:
- List of unexpected exceptions
- Register corruption patterns
- Timing issues
-
Crash Analysis (if applicable):
- Last 10 interrupts before crash
- Register state at crash
- Likely root cause
Example Commands
Quick Interrupt Summary
echo "=== Interrupt Vector Summary ==="
grep "v=" /tmp/breenix-int-trace.log | awk -F'v=' '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -rn
echo "=== Privilege Level Transitions ==="
grep "CPL=" /tmp/breenix-int-trace.log | awk -F'CPL=' '{print $2}' | awk '{print $1}' | uniq -c
echo "=== Exception Events ==="
grep -E "v=0[0-9a-f]" /tmp/breenix-int-trace.log | grep -v "v=20" | head -20
Detailed Syscall Analysis
# Find all syscall interrupts and show register state
grep -B 2 -A 5 "v=80" /tmp/breenix-int-trace.log | less
Crash Investigation
# Show last 50 interrupts before end of log
grep "v=" /tmp/breenix-int-trace.log | tail -50
Interpreting Results
Healthy Boot Sequence
A normal Breenix boot should show:
v=20 (timer) - repeated regularly
v=80 (syscall) - when userspace runs
CPL=0 -> CPL=3 transitions when entering userspace
CPL=3 -> CPL=0 transitions on syscalls/interrupts
Problematic Patterns
-
No syscalls (v=80):
- Userspace never started
- Process creation failed
- Check for earlier exceptions
-
No CPL=3:
- Never entered userspace
- Privilege transition failed
- Check interrupt return path
-
Exception storm:
- Same exception repeating rapidly
- Handler not fixing root cause
- Infinite loop in exception handling
-
CPU reset events:
- Triple fault occurred
- Unrecoverable state
- Check for double faults before reset
Common Debug Flags
Other useful QEMU debug flag combinations:
# Just interrupts
export BREENIX_QEMU_DEBUG_FLAGS="int"
# Interrupts + MMU/page tables
export BREENIX_QEMU_DEBUG_FLAGS="int,mmu"
# Interrupts + all exceptions
export BREENIX_QEMU_DEBUG_FLAGS="int,cpu_reset,guest_errors,exception"
# Everything (very verbose)
export BREENIX_QEMU_DEBUG_FLAGS="int,cpu_reset,guest_errors,mmu,exception"
Notes
- The trace log can be very large (10MB+ for full boot)
- Focus on specific time windows or interrupt types
- Use
head/tailto avoid overwhelming output - Correlate with Breenix's own serial output logs for context
- Timer interrupt (v=20) is the most common - filter it out to see other events
Didn't find tool you were looking for?