@@ -62,9 +62,16 @@ void timer_start(unsigned long duration_us)
void timer_stop(void)
{
if (cpu_has_extension(smp_processor_id(), ISA_SSTC)) {
- csr_write(CSR_STIMECMP, ULONG_MAX);
+ /*
+ * Subtract one from ULONG_MAX to workaround QEMU using that
+ * exact number to decide *not* to update the timer. IOW, if
+ * we used ULONG_MAX, then we wouldn't stop the timer at all,
+ * but one less is still a big number ("infinity") and it gets
+ * QEMU to do what we want.
+ */
+ csr_write(CSR_STIMECMP, ULONG_MAX - 1);
if (__riscv_xlen == 32)
- csr_write(CSR_STIMECMPH, ULONG_MAX);
+ csr_write(CSR_STIMECMPH, ULONG_MAX - 1);
} else if (sbi_probe(SBI_EXT_TIME)) {
struct sbiret ret = sbi_set_timer(ULONG_MAX);
assert(ret.error == SBI_SUCCESS);
QEMU doesn't stop a pending timer when UINT64_MAX is written to stimecmp, see QEMU commit ae0edf2188b3 ("target/riscv: No need to re-start QEMU timer when timecmp == UINT64_MAX"). We should probably change that in QEMU, but we need a solution in kvm-unit-tests anyway in order to support older QEMU versions. A bit of an ugly workaround is to simply subtract one from UINT64_MAX, which is still a really big number, but not the exact number QEMU is using to decide it should skip the timer update. Signed-off-by: Andrew Jones <andrew.jones@linux.dev> --- lib/riscv/timer.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)