Hi,
I recently needed to slow down time within a virtual machine, due to a
timeout being hit because my QEMU binary which was not fast enough (gcov
debug build if you're curious about the use case).
Currently, people tend to use -icount shift=X with low values for that,
as it roughly maps time to how many instructions were ran.
As well, I've been working on ips (Instructions per second) plugin [1],
which allows to slow down QEMU execution by sleeping, as suggested by
Alex. It's using a new clock update API [2], that is limited to move
time faster (jump to future time), but not slower.
After looking at how all this implemented, I am wondering why we don't
simply fake real time QEMU is using as a reference, which is based on
gettimeofday [3].
Using faketime, which fakes gettimeofday I've been able to manipulate
QEMU time:
- faketime -f '+0 x10' qemu-system-aarch64: boot timestamp is 14s
- faketime -f '+0 x0.1' qemu-system-aarch64: boot timestamp is 0.13s
In both cases, the real boot time (QEMU execution) is around 3s.
It works as expected, speeding or slowing execution without impacting
QEMU speed itself, which can run without needing to do any artificial
sleep or clock manipulation. If a program in guest vm sleeps with an
absolute time, it will be multiplied by the factor, which results in
significant slowdown. But it can't be avoided, by design.
By using a time factor big enough (x200), it can even trigger
rcu_preempt stall detection in Linux guest kernel.
As it seems a bit too good to be true, time for questions:
- Has it already been considered?
- Any obvious downside I might have skipped?
- Would that be interesting to offer such a feature in QEMU itself
(-time-dilation 0.10)?
[1]
https://gitlab.com/qemu-project/qemu/-/commit/72db6d54a4a9203736261fc63f32f6cd3486b7e4
[2]
https://gitlab.com/qemu-project/qemu/-/commit/847a65dd76bf1868c7966a2b2608dcd00cb68dc7
[3]
https://gitlab.com/qemu-project/qemu/-/blob/master/include/qemu/timer.h?ref_type=heads#L809
[4] https://github.com/wolfcw/libfaketime
Regards,
Pierrick
