On 7/3/25 1:36 PM, Dr. David Alan Gilbert wrote:
* Pierrick Bouvier (pierrick.bouv...@linaro.org) wrote:
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?
Not that I'm aware, but there are a couple of things you might find useful to
look
at; there is the'driftifx' option with the suboption 'slew' and the
LOST_TICK_POLICY
flags (and option?) - I've never looked into how they work, but they're intended
to correct qemu time slowly in some cases - maybe it's a hint to places to glue
such a hack in?
Looking at it, it simply delivers more timer ticks at a faster rate when
they were missed in some cases (like when guest is paused). It's quite
different from altering time for the guest only.
You talk of using 'sleep' to slow the CPU down, however there is some code
in migration to slow CPUs down (but not clocks) to limit the rate at which
they generate migration data. I think it's more subtle than a simple sleep,
running something on each CPU thread to sleep.
The 'sleep' approach mentioned is used in plugin ips, but it has some
caveats, as explained. In this case, we just can slow down execution by
blocking cpu run from various plugin hooks. There is no simple solution
to accelerate it.
Dave
- 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
