On 6/27/25 5:24 PM, Pierrick Bouvier wrote:
Depending on host cpu speed, and QEMU optimization level, it may sometimes be
needed to slow or accelerate time guest is perceiving. A common scenario is
hitting a timeout during a boot process, because some operations were not
finished on time.
An existing solution for that is -icount shift=X, with low values, which will
roughly map virtual time to how many instructions were executed.
This series introduces another approach, based on faking host time returned to
the guest, by applying a time-dilation factor. Time will go slower/faster for
the guest, without impacting QEMU emulation speed.
It may eventually be used to fix some of the timeouts we hit in CI, by slowing
down time in VM, to be less sensitive to varying cpu performance.
v2
--
In review, Paolo mentioned timers deadline should redilated in the other
direction. After going through this part, it seems that arrival is always based
on one of the clocks we have (which is dilated already), so I don't think we
should redilate that, as this would create a discordance between time set, and
real time when this happen. Feel free to correct me if this is wrong.
- keep start time per clock and apply accordingly
- apply time dilation for cpu_get_host_ticks as well
- use a default factor of 1.0
- rename cli option to -rtc speed-factor
- forbid to use option with kvm, as time is not provided by QEMU for guest
Pierrick Bouvier (2):
qemu/timer: introduce time dilation factor
system/rtc: introduce -rtc speed-factor option
include/qemu/timer.h | 60 ++++++++++++++++++++++++++++------------
system/rtc.c | 11 ++++++++
system/vl.c | 9 ++++++
util/qemu-timer-common.c | 7 +++++
qemu-options.hx | 7 ++++-
5 files changed, 75 insertions(+), 19 deletions(-)
Another ping on this series.
Paolo, do you have any opinion about the comment in v2 I added in the
cover letter? Especially to not modify the arrival date for timers.
Thanks,
Pierrick
