* 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? 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 |_______/
