1 files changed, 67 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/118/architecture-risc-v/493 b/results/classifier/zero-shot/118/architecture-risc-v/493
new file mode 100644
index 00000000..21e555ea
--- /dev/null
+++ b/results/classifier/zero-shot/118/architecture-risc-v/493
@@ -0,0 +1,67 @@
+risc-v: 0.995
+architecture: 0.955
+graphic: 0.849
+device: 0.810
+performance: 0.696
+semantic: 0.644
+files: 0.588
+kernel: 0.547
+register: 0.533
+vnc: 0.466
+socket: 0.369
+mistranslation: 0.368
+network: 0.353
+debug: 0.295
+boot: 0.272
+VMM: 0.271
+arm: 0.242
+permissions: 0.230
+peripherals: 0.215
+PID: 0.206
+ppc: 0.193
+TCG: 0.157
+user-level: 0.146
+assembly: 0.130
+hypervisor: 0.121
+virtual: 0.099
+i386: 0.079
+KVM: 0.064
+x86: 0.016
+--------------------
+risc-v: 0.998
+performance: 0.905
+kernel: 0.184
+register: 0.116
+TCG: 0.113
+debug: 0.104
+files: 0.080
+hypervisor: 0.038
+assembly: 0.032
+architecture: 0.029
+device: 0.021
+virtual: 0.015
+semantic: 0.008
+peripherals: 0.007
+user-level: 0.005
+vnc: 0.003
+PID: 0.003
+network: 0.002
+KVM: 0.002
+boot: 0.002
+VMM: 0.002
+arm: 0.001
+socket: 0.001
+graphic: 0.001
+permissions: 0.001
+mistranslation: 0.000
+i386: 0.000
+ppc: 0.000
+x86: 0.000
+
+RISC-V: Setting mtimecmp to -1 immediately triggers an interrupt
+Description of problem:
+When setting mtimecmp to -1, which should set a timer infinitely far in the future, a timer interrupt is triggered immediately. This happens for most values over 2^61. It is the same for both 32-bit and 64-bit, and for M-mode writing to mtimecmp directly and S-mode using OpenSBI.
+
+I have looked through the source code, and the problem is in the function `sifive_clint_write_mtimecmp`, in the file `/hw/intc/sifive_clint.c`. First, the muldiv64 multiplies diff with 100, causing an overflow (at least for -M virt, other machines might use a different timebase_freq). Then, the unsigned `next` is passed to `timer_mod`, which takes a signed integer. In `timer_mod_ns_locked` the value is set to `MAX(next, 0)`, which means that if the MSB of `next` was set, the interrupt happens immediately. This means that it is impossible to set timers more than 2^63 nanoseconds in the future.
+
+This problem basically only affects programs which disable timer interrupts by setting the next one infinitely far in the future. However, the SBI doc specifically says that this is a valid approach, so it should be supported. Using the MSB doesn't work without changing code functionality in QEMU, but it should be sufficient to cap `next` at the maximum signed value.