diff options
| author | Christian Krinitsin <mail@krinitsin.com> | 2025-06-16 16:59:00 +0000 |
|---|---|---|
| committer | Christian Krinitsin <mail@krinitsin.com> | 2025-06-16 16:59:33 +0000 |
| commit | 9aba81d8eb048db908c94a3c40c25a5fde0caee6 (patch) | |
| tree | b765e7fb5e9a3c2143c68b0414e0055adb70e785 /results/classifier/118/none/1617 | |
| parent | b89a938452613061c0f1f23e710281cf5c83cb29 (diff) | |
| download | emulator-bug-study-9aba81d8eb048db908c94a3c40c25a5fde0caee6.tar.gz emulator-bug-study-9aba81d8eb048db908c94a3c40c25a5fde0caee6.zip | |
add 18th iteration of classifier
Diffstat (limited to 'results/classifier/118/none/1617')
| -rw-r--r-- | results/classifier/118/none/1617 | 92 |
1 files changed, 92 insertions, 0 deletions
diff --git a/results/classifier/118/none/1617 b/results/classifier/118/none/1617 new file mode 100644 index 00000000..4834d106 --- /dev/null +++ b/results/classifier/118/none/1617 @@ -0,0 +1,92 @@ +peripherals: 0.445 +user-level: 0.420 +graphic: 0.414 +semantic: 0.410 +vnc: 0.362 +hypervisor: 0.357 +permissions: 0.353 +mistranslation: 0.329 +risc-v: 0.327 +debug: 0.320 +VMM: 0.313 +ppc: 0.306 +assembly: 0.294 +arm: 0.290 +performance: 0.288 +virtual: 0.285 +architecture: 0.275 +device: 0.268 +PID: 0.261 +network: 0.242 +TCG: 0.242 +x86: 0.232 +register: 0.212 +KVM: 0.207 +socket: 0.203 +boot: 0.191 +kernel: 0.189 +files: 0.152 +i386: 0.113 + +RISC-V: VS external IRQ can be taken in M-mode +Description of problem: +The RISC-V specification states that `VS-level interrupts and guest external interrupts are always delegated past M-mode to HS mode.` +I happened to come across a situation where QEMU takes the vs_external IRQ in machine mode. +Steps to reproduce: +1. Enable IRQs globally (mstatus, vsstatus) +2. Set hstatus.VGEIN to a legal value +3. Write -1 to mie +4. Write -1 to hvip + +I included a binary that should be able to reproduce the issue. + +I use a vectored setup for mtvec and as soon as the VSEIP bit in hvip has been set the machine jumps to mtvec.vsei. +To confirm that I actually went to mtvec and not somewhere with a faulty print I also performed an ecall and that was reported as an M mode ecall. +Additional information: +``` +TRACE: [hart_ctrl.c:35] STARTING CPU 0 +DEBUG: [trap_handling.c: 886] Setting up trap handlers +DEBUG: [aia_ctrl.c: 377] Initializing interrupt controller +TRACE: [main.c:31] Writing -1 to mie +TRACE: [main.c:33] Writing -1 to hvip +riscv_cpu_do_interrupt: hart:0, async:1, cause:000000000000000a, epc:0x0000000080000114, tval:0x0000000000000000, desc=vs_external +ERROR: [trap_handling.c:280] mtvec_vsei should be unreachable +mstatus = 0x0000000a000038a2 hstatus: + SIE = 1 VSXL[1:0] = 2 + MIE = 0 VTSR = 0 + SPIE = 1 VTW = 0 + UBE = 0 VTVM = 0 + MPIE = 1 VGEIN[5:0] = 1 + SPP = 0 HU = 0 + VS = 0 SPVP = 0 + MPP = 3 SPV = 0 + FS = 1 GVA = 0 + MPRV = 0 VSBE = 0 + SUM = 0 + MXR = 0 + TVM = 0 + TW = 0 + TSR = 0 + UXL = 2 + SXL = 2 + SBE = 0 + MBE = 0 + GVA = 0 + MPV = 0 +mie mip mideleg hvip + ssie (1) = 1 ssip (1) = 0 ssi (1) = 0 ssip (1) = 0 + vssie(2) = 1 vssip(2) = 1 vssi (2) = 0 vssip(2) = 1 + msie (3) = 1 msip (3) = 0 msi (3) = 0 msip (3) = 0 + stie (5) = 1 stip (5) = 0 sti (5) = 0 stip (5) = 0 + vstie(6) = 1 vstip(6) = 0 vsti (6) = 0 vstip(6) = 0 + mtie (7) = 1 mtip (7) = 0 mti (7) = 0 mtip (7) = 0 + seie (9) = 1 seip (9) = 0 sei (9) = 0 seip (9) = 0 + vseie(10) = 1 vseip(10) = 1 vsei (10) = 0 vseip(10) = 1 + meie (11) = 1 meip (11) = 0 mei (11) = 0 meip (11) = 0 + sgeie(12) = 1 sgeip(12) = 0 sgei (12) = 0 sgeip(12) = 0 +DEBUG: [trap_handling.c: 28] hart_ctrl.kill_hart = 0x8000a00c +TRACE: [trap_handling.c:29] Program done, exiting +QEMU: Terminated +``` +Reproducer of the problem: +[main](/uploads/26a5698ce948149ca9d34f6b3dfac6a4/main) |