diff options
Diffstat (limited to 'results/classifier/118/architecture-risc-v/493')
| -rw-r--r-- | results/classifier/118/architecture-risc-v/493 | 67 |
1 files changed, 0 insertions, 67 deletions
diff --git a/results/classifier/118/architecture-risc-v/493 b/results/classifier/118/architecture-risc-v/493 deleted file mode 100644 index 21e555eaf..000000000 --- a/results/classifier/118/architecture-risc-v/493 +++ /dev/null @@ -1,67 +0,0 @@ -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. |