17.11.1. irq.ko
Brute force monitor every shared interrupt that will accept us:
./run --eval-after 'insmod irq.ko' --graphic
Source: kernel_modules/irq.c.
Now try the following:
-
press a keyboard key and then release it after a few seconds
-
press a mouse key, and release it after a few seconds
-
move the mouse around
Outcome: dmesg shows which IRQ was fired for each action through messages of type:
handler irq = 1 dev = 250
dev is the character device for the module and never changes, as can be confirmed by:
grep lkmc_irq /proc/devices
The IRQs that we observe are:
-
1for keyboard press and release.If you hold the key down for a while, it starts firing at a constant rate. So this happens at the hardware level!
-
12mouse actions
This only works if for IRQs for which the other handlers are registered as IRQF_SHARED.
We can see which ones are those, either via dmesg messages of type:
genirq: Flags mismatch irq 0. 00000080 (myirqhandler0) vs. 00015a00 (timer) request_irq irq = 0 ret = -16 request_irq irq = 1 ret = 0
which indicate that 0 is not, but 1 is, or with:
cat /proc/interrupts
which shows:
0: 31 IO-APIC 2-edge timer 1: 9 IO-APIC 1-edge i8042, myirqhandler0
so only 1 has myirqhandler0 attached but not 0.
The QEMU monitor also has some interrupt statistics for x86_64:
./qemu-monitor info irq
TODO: properly understand how each IRQ maps to what number.