From: Pierrick Bouvier <pierrick.bouvier@linaro.org>
To: "Alex Bennée" <alex.bennee@linaro.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Peter Maydell" <peter.maydell@linaro.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: Controlling time in QEMU
Date: Tue, 10 Jun 2025 14:30:05 -0700 [thread overview]
Message-ID: <6a25710c-f576-4892-a8f0-4ee64bbdcad3@linaro.org> (raw)
In-Reply-To: <b3cef05e-8bb5-4390-8b43-914adca3b3b6@linaro.org>
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
next prev parent reply other threads:[~2025-06-10 21:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-06 19:03 Controlling time in QEMU Pierrick Bouvier
2025-06-10 10:22 ` Bernhard Beschow
2025-06-10 14:47 ` Pierrick Bouvier
2025-06-10 21:30 ` Pierrick Bouvier [this message]
2025-07-03 20:36 ` Dr. David Alan Gilbert
2025-07-08 17:43 ` Pierrick Bouvier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6a25710c-f576-4892-a8f0-4ee64bbdcad3@linaro.org \
--to=pierrick.bouvier@linaro.org \
--cc=alex.bennee@linaro.org \
--cc=berrange@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).