On 11/01/13 20:58, Stefan Weil wrote: > Am 11.01.2013 14:40, schrieb Wolfgang Mauerer: >> > For slow targets and fast hosts, the emulation may be faster >> > than the actual hardware, which can be undesirable for various >> > reasons. Add a run-time option to slow down the emulation >> > by sleeping in the CPU emulation. >> > >> > Signed-off-by: Wolfgang Mauerer<wolfgang.maue...@siemens.com> >> > --- >> > cpus.c | 34 ++++++++++++++++++++++++++++++++++ >> > include/qemu-common.h | 2 ++ >> > qemu-options.hx | 13 +++++++++++++ >> > vl.c | 10 ++++++++++ >> > 4 files changed, 59 insertions(+), 0 deletions(-) >> > >> > diff --git a/cpus.c b/cpus.c >> > index 4a7782a..41a9e0c 100644 >> > --- a/cpus.c >> > +++ b/cpus.c >> > @@ -106,6 +106,11 @@ static QEMUTimer *icount_warp_timer; >> > static int64_t vm_clock_warp_start; >> > static int64_t qemu_icount; >> > >> > +static double slowdown_factor = 0.0; >> > +#ifndef _WIN32 >> > +static struct timespec slowdown_delay; >> > +#endif >> > + >> > > Hi, > > slowdown_delay is used in configure_slowdown unconditionally, > so I don't expect that the _WIN32 case will compile. > > What about using g_usleep? It avoids the conditional compilation. > > Is the comparison of double value "slowdown_factor" with 0.0 > time critical, or do all QEMU platforms have a fast FPU? > > Setting a boolean value once and testing that value would > be much faster of course.
I'm not sure if the floating point comparison has a significant impact on any important platform, but using a boolean variable makes the code more similar to the icount mechanism, so I've changed it accordingly. Using g_usleep is a good idea to let the conditional _WIN32 parts go away. Revised patch follows. Cheers, Wolfgang
