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(-)
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(-) -- 2.47.2
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(-) > Trying another ping on this series. It has been useful to reduce number of interruptions in a guest when running on a slow machine. Regards, Pierrick
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
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(-) > Gentle ping on this series. Regards, Pierrick
© 2016 - 2025 Red Hat, Inc.