On 7/3/25 1:36 PM, Dr. David Alan Gilbert wrote:
* 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 us
* 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 us
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 l
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 fr
Am 6. Juni 2025 19:03:32 UTC schrieb 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
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 ti
