Re: Faster than real-time execution

[Alex Bennée]

"frankwmiller frankwmiller.net" <frankwmiller@frankwmiller.net> writes:

> Greetings, 
>   
> I've been contemplating using QEMU for faster-than-real-time execution of 
> SPARC executables on an X86-64 machine.
>   It appears from the base architecture of QEMU that this is not possible if 
> QEMU is using JIT of the SPARC to x86-84
> since the resulting x86-64 will run on the hardware at the processor clock 
> speed and there's not really any way around
> that. 
>   
> However, is it possible to do something like this.  Execute the SPARC 
> instructions in simulation, i.e. without any JIT, and
> then since everything is executed as simulated SPARC instructions, 
> essentially speed up time in the simulated
> environment and execute FRT that way?

Have a look at icount mode:

  -icount 
[shift=N|auto][,align=on|off][,sleep=on|off][,rr=record|replay,rrfile=filename[,rrsnapshot=snapshot]]

      Enable virtual instruction counter. The virtual cpu will execute one 
instruction every 2^N ns of virtual time. If auto is specified then the virtual 
cpu speed will be automatically adjusted to keep virtual time within a few 
seconds of real time.

      Note that while this option can give deterministic behavior, it does not 
provide cycle accurate emulation. Modern CPUs contain superscalar out of order 
cores with complex cache hierarchies. The number of instructions executed often 
has little or no correlation with actual performance.

      When the virtual cpu is sleeping, the virtual time will advance at 
default speed unless sleep=on is specified. With sleep=on, the virtual time 
will jump to the next timer deadline instantly whenever the virtual cpu goes to 
sleep mode and will not advance if no timer is enabled. This behavior gives 
deterministic execution times from the guest point of view. The default if 
icount is enabled is sleep=off. sleep=on cannot be used together with either 
shift=auto or align=on.

      align=on will activate the delay algorithm which will try to synchronise 
the host clock and the virtual clock. The goal is to have a guest running at 
the real frequency imposed by the shift option. Whenever the guest clock is 
behind the host clock and if align=on is specified then we print a message to 
the user to inform about the delay. Currently this option does not work when 
shift is auto. Note: The sync algorithm will work for those shift values for 
which the guest clock runs ahead of the host clock. Typically this happens when 
the shift value is high (how high depends on the host machine). The default if 
icount is enabled is align=off.

      When the rr option is specified deterministic record/replay is enabled. 
The rrfile= option must also be provided to specify the path to the replay log. 
In record mode data is written to this file, and in replay mode it is read 
back. If the rrsnapshot option is given then it specifies a VM snapshot name. 
In record mode, a new VM snapshot with the given name is created at the start 
of execution recording. In replay mode this option specifies the snapshot name 
used to load the initial VM state.


You can read more about how it works at: 
https://qemu.readthedocs.io/en/latest/devel/tcg-icount.html

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro