Controlling time in QEMU

Controlling time in QEMU

[Pierrick Bouvier]

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

Re: Controlling time in QEMU

[Bernhard Beschow]

Am 6. Juni 2025 19:03:32 UTC schrieb Pierrick Bouvier <pierrick.bouvier@linaro.org>:
>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?

The only downside I can see is that it seems to disturb QEMU's internal timekeeping. The GTK gui freezes for quite some time when the time facor is very low, e.g. 0.001.

Best regards,
Bernhard

>- 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
>

Re: Controlling time in QEMU

[Pierrick Bouvier]

Hi Bernard,

On 6/10/25 3:22 AM, Bernhard Beschow wrote:
>> 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?
> 
> The only downside I can see is that it seems to disturb QEMU's internal timekeeping. The GTK gui freezes for quite some time when the time facor is very low, e.g. 0.001.
> 
> Best regards,
> Bernhard
>

Yes, faking all the calls to gettimeofday is not the best solution, as 
it impacts qemu beyond its clock management.
This could be a good argument to have something implemented in QEMU, 
which impacts only get_clock() and get_clock_realtime().

Thanks,
Pierrick

Re: Controlling time in QEMU

[Pierrick Bouvier]

On 6/6/25 12:03 PM, Pierrick Bouvier 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?
> - 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

Series sent:
https://lore.kernel.org/qemu-devel/20250610212829.2818792-1-pierrick.bouvier@linaro.org/T/#t

Re: Controlling time in QEMU

[Dr. David Alan Gilbert]

* Pierrick Bouvier (pierrick.bouvier@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?

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.

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
> 
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/

Re: Controlling time in QEMU

[Pierrick Bouvier]

On 7/3/25 1:36 PM, Dr. David Alan Gilbert wrote:
> * Pierrick Bouvier (pierrick.bouvier@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
>>