diff options
Diffstat (limited to 'gitlab/issues/target_riscv/host_missing/accel_missing/493.toml')
| -rw-r--r-- | gitlab/issues/target_riscv/host_missing/accel_missing/493.toml | 19 |
1 files changed, 0 insertions, 19 deletions
diff --git a/gitlab/issues/target_riscv/host_missing/accel_missing/493.toml b/gitlab/issues/target_riscv/host_missing/accel_missing/493.toml deleted file mode 100644 index 438ad6f5e..000000000 --- a/gitlab/issues/target_riscv/host_missing/accel_missing/493.toml +++ /dev/null @@ -1,19 +0,0 @@ -id = 493 -title = "RISC-V: Setting mtimecmp to -1 immediately triggers an interrupt" -state = "closed" -created_at = "2021-07-21T09:45:58.217Z" -closed_at = "2021-09-01T09:56:33.052Z" -labels = ["target: riscv", "workflow::In Progress"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/493" -host-os = "Arch Linux" -host-arch = "x86" -qemu-version = "6.0.50" -guest-os = "Bare metal" -guest-arch = "RISC-V" -description = """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.""" -reproduce = "n/a" -additional = "n/a" |