Re: [Qemu-devel] icount mode

[Alex Bennée]

Wu, Wentong <address@hidden> writes:

> Hi all,
>
> Recently I'm using Qemu TCG icount mode, from the code I found Qemu
> timers run at 1GHz, and for ArmV7M example, there will be conversion

Are you talking about:

  #define ARM_CPU_FREQ 1000000000 /* FIXME: 1 GHz, should be configurable */

because as far as I can tell that only affects the scaling factors
applied to PMU counters. The internal counters (CNTFRQ_EL0 and friends)
are hardwired to:

   /* Scale factor for generic timers, ie number of ns per tick.
    * This gives a 62.5MHz timer.
    */
   #define GTIMER_SCALE 16

but this only affects the nominal rate the counters expire at. Software
could attempt to reprogram it and the emulation will read-as-written but
it won't actually change anything. However this only affects the clocks
- it implies nothing about how fast the core may be executing. In fact
unless you are using icount we will just run as fast a possible.

> factor from qemu timer to SysTick frequency which will be calculated
> by NANOSECONDS_PER_SECOND / SYSCLK_FRQ.

You need to be a little more precise here. ARM systems vary in the
number of timer sources they have. The qemu timers are an internal
implementation detail for providing a way to track time. The value of
SYSCLK_FRQ varies depending on what board you have launched and mostly
seems to be used to calculate the additional timer values for various
peripherals.

> But the shift value also define the target cpu frequency(2^N ns /one
> instruction), and both frequencies will be used together to calculate
> the guest timer, so I think there is buggy because of the different
> frequency, can anyone give some explanation for this? Thanks a lot!

All icount does is peg the elapsed virtual time to the number of
instructions executed (the instruction count). This means whenever the
code requests:

  qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL)

Instead of returning the number of ns the guest has been running based
on elapsed host time it will return the number of instructions run
shifted by icount_shift. So with higher shift values each instruction
sees an increased amount of virtual time pass - the practical effect
will be you see less instructions executed between timer interrupts.

>
> Also can anyone give some hints about how to give the shift value when
> use icount TCG mode?

  $QEMU $QEMU_ARGS -icount N

or

  $QEMU $QEMU_ARGS -icount shift=N

What is your interest in icount? Is it purely for determinism?

--
Alex Bennée