[Qemu-devel] [PATCH 0/3] implement a new icount_no_rt mode

[Qemu-devel] [PATCH 0/3] implement a new icount_no_rt mode

[Victor CLEMENT]

This patch adds a new icount_no_rt mode set by the new 'rt' parameter
of the icount option.
When using icount_no_rt mode, the QEMU_VIRTUAL_CLOCK will be running at
the maximal possible speed by warping the CPU sleep times to the soonest
virtual clock deadline.
The goal is to get deterministic execution times by preventing potential
latencies from qemu execution on the host machine.
The virtual cpus sleep time will be calculated but not spent, hence the
virtual time will not be realistic when looking from the host point of view
(ex. a 'sleep 10' on the guest will return almost instantly while the
guest clock wil act like 10s have really passed)

This new mode will be used for testing real-time applications inside qemu.
It makes the virtual clock "purely" virtual by removing any reference to
host clocks in the calculation of QEMU_VIRTUAL_CLOCK value.
Thus, some emulated devices which use other clocks as reference will not
work in this mode. The virtual time would be running too fast compared
to the actual "real" time.

To use this mode, one need to modify some emulators to simulate scenario
using the virtual clock and report some events using the virtual clock
too.
This kind of changes cannot be generic as the scenario will depend
on the tested application, so modified emulators are not part of this
patch set.

Victor CLEMENT (3):
  icount: implement a new icount_no_rt mode without real time cpu
    sleeping
  icount: add rt parameter to the -icount option to toogle icount_no_rt
    mode
  icount: print a warning if there is no more deadline in no_rt mode

 cpus.c          | 85 +++++++++++++++++++++++++++++++++++++++------------------
 qemu-options.hx | 12 ++++++--
 vl.c            |  3 ++
 3 files changed, 72 insertions(+), 28 deletions(-)

-- 
2.3.7

[Qemu-devel] [PATCH 1/3] icount: implement a new icount_no_rt mode without real time cpu sleeping

[Victor CLEMENT]

In this new icount_no_rt mode, the QEMU_VIRTUAL_CLOCK runs at the
maximum possible speed by warping the sleep times of the virtual cpu to the
soonest clock deadline. The virtual clock will be updated only according
the instruction counter.

Signed-off-by: Victor CLEMENT <victor.clement@openwide.fr>
---
 cpus.c | 64 ++++++++++++++++++++++++++++++++++++++++------------------------
 1 file changed, 40 insertions(+), 24 deletions(-)

diff --git a/cpus.c b/cpus.c
index de6469f..012d14b 100644
--- a/cpus.c
+++ b/cpus.c
@@ -105,6 +105,7 @@ static bool all_cpu_threads_idle(void)
 
 /* Protected by TimersState seqlock */
 
+static bool icount_no_rt;
 static int64_t vm_clock_warp_start = -1;
 /* Conversion factor from emulated instructions to virtual clock ticks.  */
 static int icount_time_shift;
@@ -393,15 +394,18 @@ void qemu_clock_warp(QEMUClockType type)
         return;
     }
 
-    /*
-     * If the CPUs have been sleeping, advance QEMU_CLOCK_VIRTUAL timer now.
-     * This ensures that the deadline for the timer is computed correctly below.
-     * This also makes sure that the insn counter is synchronized before the
-     * CPU starts running, in case the CPU is woken by an event other than
-     * the earliest QEMU_CLOCK_VIRTUAL timer.
-     */
-    icount_warp_rt(NULL);
-    timer_del(icount_warp_timer);
+    if (!icount_no_rt) {
+        /*
+         * If the CPUs have been sleeping, advance QEMU_CLOCK_VIRTUAL timer now.
+         * This ensures that the deadline for the timer is computed correctly
+         * below.
+         * This also makes sure that the insn counter is synchronized before
+         * the CPU starts running, in case the CPU is woken by an event other
+         * than the earliest QEMU_CLOCK_VIRTUAL timer.
+         */
+        icount_warp_rt(NULL);
+        timer_del(icount_warp_timer);
+    }
     if (!all_cpu_threads_idle()) {
         return;
     }
@@ -425,23 +429,35 @@ void qemu_clock_warp(QEMUClockType type)
          * interrupt to wake it up, but the interrupt never comes because
          * the vCPU isn't running any insns and thus doesn't advance the
          * QEMU_CLOCK_VIRTUAL.
-         *
-         * An extreme solution for this problem would be to never let VCPUs
-         * sleep in icount mode if there is a pending QEMU_CLOCK_VIRTUAL
-         * timer; rather time could just advance to the next QEMU_CLOCK_VIRTUAL
-         * event.  Instead, we do stop VCPUs and only advance QEMU_CLOCK_VIRTUAL
-         * after some "real" time, (related to the time left until the next
-         * event) has passed. The QEMU_CLOCK_VIRTUAL_RT clock will do this.
-         * This avoids that the warps are visible externally; for example,
-         * you will not be sending network packets continuously instead of
-         * every 100ms.
          */
-        seqlock_write_lock(&timers_state.vm_clock_seqlock);
-        if (vm_clock_warp_start == -1 || vm_clock_warp_start > clock) {
-            vm_clock_warp_start = clock;
+        if (icount_no_rt) {
+            /*
+             * We never let VCPUs sleep in async icount mode.
+             * If there is a pending QEMU_CLOCK_VIRTUAL timer we just advance
+             * to the next QEMU_CLOCK_VIRTUAL event and notify it.
+             * It is useful when we want a deterministic execution time,
+             * isolated from host latencies.
+             */
+            seqlock_write_lock(&timers_state.vm_clock_seqlock);
+            timers_state.qemu_icount_bias += deadline;
+            seqlock_write_unlock(&timers_state.vm_clock_seqlock);
+            qemu_clock_notify(QEMU_CLOCK_VIRTUAL);
+        } else {
+            /*
+             * We do stop VCPUs and only advance QEMU_CLOCK_VIRTUAL after some
+             * "real" time, (related to the time left until the next event) has
+             * passed. The QEMU_CLOCK_VIRTUAL_RT clock will do this.
+             * This avoids that the warps are visible externally; for example,
+             * you will not be sending network packets continuously instead of
+             * every 100ms.
+             */
+            seqlock_write_lock(&timers_state.vm_clock_seqlock);
+            if (vm_clock_warp_start == -1 || vm_clock_warp_start > clock) {
+                vm_clock_warp_start = clock;
+            }
+            seqlock_write_unlock(&timers_state.vm_clock_seqlock);
+            timer_mod_anticipate(icount_warp_timer, clock + deadline);
         }
-        seqlock_write_unlock(&timers_state.vm_clock_seqlock);
-        timer_mod_anticipate(icount_warp_timer, clock + deadline);
     } else if (deadline == 0) {
         qemu_clock_notify(QEMU_CLOCK_VIRTUAL);
     }
-- 
2.3.7

[Qemu-devel] [PATCH 2/3] icount: add rt parameter to the -icount option to toogle icount_no_rt mode

[Victor CLEMENT]

The 'rt' parameter sets the icount_no_rt mode, which is not enabled by
default. To enable it, add the 'nort' parameter (or 'rt=off') to the
qemu -icount option.

Signed-off-by: Victor CLEMENT <victor.clement@openwide.fr>
---
 cpus.c          | 15 +++++++++++++--
 qemu-options.hx | 12 ++++++++++--
 vl.c            |  3 +++
 3 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/cpus.c b/cpus.c
index 012d14b..eac3e19 100644
--- a/cpus.c
+++ b/cpus.c
@@ -520,9 +520,18 @@ void configure_icount(QemuOpts *opts, Error **errp)
         }
         return;
     }
+
+    icount_no_rt = !qemu_opt_get_bool(opts, "rt", true);
+    if (!icount_no_rt) {
+        icount_warp_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL_RT,
+                                         icount_warp_rt, NULL);
+    }
+
     icount_align_option = qemu_opt_get_bool(opts, "align", false);
-    icount_warp_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL_RT,
-                                     icount_warp_rt, NULL);
+
+    if (icount_align_option && icount_no_rt) {
+        error_setg(errp, "align and nort options are incompatible");
+    }
     if (strcmp(option, "auto") != 0) {
         errno = 0;
         icount_time_shift = strtol(option, &rem_str, 0);
@@ -533,6 +542,8 @@ void configure_icount(QemuOpts *opts, Error **errp)
         return;
     } else if (icount_align_option) {
         error_setg(errp, "shift=auto and align=on are incompatible");
+    } else if (icount_no_rt) {
+        error_setg(errp, "shift=auto and nort are incompatible");
     }
 
     use_icount = 2;
diff --git a/qemu-options.hx b/qemu-options.hx
index ec356f6..531bed7 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -3086,9 +3086,10 @@ re-inject them.
 ETEXI
 
 DEF("icount", HAS_ARG, QEMU_OPTION_icount, \
-    "-icount [shift=N|auto][,align=on|off]\n" \
+    "-icount [shift=N|auto][,align=on|off][,nort]\n" \
     "                enable virtual instruction counter with 2^N clock ticks per\n" \
-    "                instruction and enable aligning the host and virtual clocks\n", QEMU_ARCH_ALL)
+    "                instruction, enable aligning the host and virtual clocks\n" \
+    "                or disable real time cpu sleeping\n", QEMU_ARCH_ALL)
 STEXI
 @item -icount [shift=@var{N}|auto]
 @findex -icount
@@ -3097,6 +3098,13 @@ instruction every 2^@var{N} ns of virtual time.  If @code{auto} is specified
 then the virtual cpu speed will be automatically adjusted to keep virtual
 time within a few seconds of real time.
 
+When the virtual cpu is sleeping, the virtual time will advance at default
+speed unless @option{nort} is specified.
+With @option{nort}, 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 give deterministic execution times from
+the guest point of view.
+
 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
diff --git a/vl.c b/vl.c
index 15bccc4..0c377e8 100644
--- a/vl.c
+++ b/vl.c
@@ -470,6 +470,9 @@ static QemuOptsList qemu_icount_opts = {
         }, {
             .name = "align",
             .type = QEMU_OPT_BOOL,
+        }, {
+            .name = "rt",
+            .type = QEMU_OPT_BOOL,
         },
         { /* end of list */ }
     },
-- 
2.3.7

[Qemu-devel] [PATCH 3/3] icount: print a warning if there is no more deadline in no_rt mode

[Victor CLEMENT]

While qemu is running in icount_no_rt mode, a warning will be printed
when no timer deadline is set.
As this mode is intended for getting deterministic virtual time, if no
timer is set on the virtual clock this determinism is broken.

Signed-off-by: Victor CLEMENT <victor.clement@openwide.fr>
---
 cpus.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/cpus.c b/cpus.c
index eac3e19..c358c2e 100644
--- a/cpus.c
+++ b/cpus.c
@@ -419,6 +419,12 @@ void qemu_clock_warp(QEMUClockType type)
     clock = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL_RT);
     deadline = qemu_clock_deadline_ns_all(QEMU_CLOCK_VIRTUAL);
     if (deadline < 0) {
+        static bool notified;
+        if (icount_no_rt && !notified) {
+            fprintf(stderr, "cpus: WARNING: icount no_rt enabled and no more \
+active timer\n");
+            notified = true;
+        }
         return;
     }
 
-- 
2.3.7

Re: [Qemu-devel] [PATCH 1/3] icount: implement a new icount_no_rt mode without real time cpu sleeping

[Paolo Bonzini]

On 27/05/2015 13:52, Victor CLEMENT wrote:
> In this new icount_no_rt mode, the QEMU_VIRTUAL_CLOCK runs at the
> maximum possible speed by warping the sleep times of the virtual cpu to the
> soonest clock deadline. The virtual clock will be updated only according
> the instruction counter.
> 
> Signed-off-by: Victor CLEMENT <victor.clement@openwide.fr>
> ---
>  cpus.c | 64 ++++++++++++++++++++++++++++++++++++++++------------------------
>  1 file changed, 40 insertions(+), 24 deletions(-)
> 
> diff --git a/cpus.c b/cpus.c
> index de6469f..012d14b 100644
> --- a/cpus.c
> +++ b/cpus.c
> @@ -105,6 +105,7 @@ static bool all_cpu_threads_idle(void)
>  
>  /* Protected by TimersState seqlock */
>  
> +static bool icount_no_rt;

It is somewhat hard to read the code due to double negations.  What
about "-icount sleep=[yes|no]" and naming the variable "icount_sleep"?

>  static int64_t vm_clock_warp_start = -1;
>  /* Conversion factor from emulated instructions to virtual clock ticks.  */
>  static int icount_time_shift;
> @@ -393,15 +394,18 @@ void qemu_clock_warp(QEMUClockType type)
>          return;
>      }
>  
> -    /*
> -     * If the CPUs have been sleeping, advance QEMU_CLOCK_VIRTUAL timer now.
> -     * This ensures that the deadline for the timer is computed correctly below.
> -     * This also makes sure that the insn counter is synchronized before the
> -     * CPU starts running, in case the CPU is woken by an event other than
> -     * the earliest QEMU_CLOCK_VIRTUAL timer.
> -     */
> -    icount_warp_rt(NULL);
> -    timer_del(icount_warp_timer);
> +    if (!icount_no_rt) {
> +        /*
> +         * If the CPUs have been sleeping, advance QEMU_CLOCK_VIRTUAL timer now.
> +         * This ensures that the deadline for the timer is computed correctly
> +         * below.
> +         * This also makes sure that the insn counter is synchronized before
> +         * the CPU starts running, in case the CPU is woken by an event other
> +         * than the earliest QEMU_CLOCK_VIRTUAL timer.
> +         */
> +        icount_warp_rt(NULL);
> +        timer_del(icount_warp_timer);
> +    }
>      if (!all_cpu_threads_idle()) {
>          return;
>      }
> @@ -425,23 +429,35 @@ void qemu_clock_warp(QEMUClockType type)
>           * interrupt to wake it up, but the interrupt never comes because
>           * the vCPU isn't running any insns and thus doesn't advance the
>           * QEMU_CLOCK_VIRTUAL.
> -         *
> -         * An extreme solution for this problem would be to never let VCPUs
> -         * sleep in icount mode if there is a pending QEMU_CLOCK_VIRTUAL
> -         * timer; rather time could just advance to the next QEMU_CLOCK_VIRTUAL
> -         * event.  Instead, we do stop VCPUs and only advance QEMU_CLOCK_VIRTUAL
> -         * after some "real" time, (related to the time left until the next
> -         * event) has passed. The QEMU_CLOCK_VIRTUAL_RT clock will do this.
> -         * This avoids that the warps are visible externally; for example,
> -         * you will not be sending network packets continuously instead of
> -         * every 100ms.
>           */
> -        seqlock_write_lock(&timers_state.vm_clock_seqlock);
> -        if (vm_clock_warp_start == -1 || vm_clock_warp_start > clock) {
> -            vm_clock_warp_start = clock;
> +        if (icount_no_rt) {
> +            /*
> +             * We never let VCPUs sleep in async icount mode.

s/async icount/sleep=no/

?

Otherwise the series looks good.

Paolo

> +             * If there is a pending QEMU_CLOCK_VIRTUAL timer we just advance
> +             * to the next QEMU_CLOCK_VIRTUAL event and notify it.
> +             * It is useful when we want a deterministic execution time,
> +             * isolated from host latencies.
> +             */
> +            seqlock_write_lock(&timers_state.vm_clock_seqlock);
> +            timers_state.qemu_icount_bias += deadline;
> +            seqlock_write_unlock(&timers_state.vm_clock_seqlock);
> +            qemu_clock_notify(QEMU_CLOCK_VIRTUAL);
> +        } else {
> +            /*
> +             * We do stop VCPUs and only advance QEMU_CLOCK_VIRTUAL after some
> +             * "real" time, (related to the time left until the next event) has
> +             * passed. The QEMU_CLOCK_VIRTUAL_RT clock will do this.
> +             * This avoids that the warps are visible externally; for example,
> +             * you will not be sending network packets continuously instead of
> +             * every 100ms.
> +             */
> +            seqlock_write_lock(&timers_state.vm_clock_seqlock);
> +            if (vm_clock_warp_start == -1 || vm_clock_warp_start > clock) {
> +                vm_clock_warp_start = clock;
> +            }
> +            seqlock_write_unlock(&timers_state.vm_clock_seqlock);
> +            timer_mod_anticipate(icount_warp_timer, clock + deadline);
>          }
> -        seqlock_write_unlock(&timers_state.vm_clock_seqlock);
> -        timer_mod_anticipate(icount_warp_timer, clock + deadline);
>      } else if (deadline == 0) {
>          qemu_clock_notify(QEMU_CLOCK_VIRTUAL);
>      }
> 

Re: [Qemu-devel] [PATCH 0/3] implement a new icount_no_rt mode

[Paolo Bonzini]

On 27/05/2015 13:52, Victor CLEMENT wrote:
> To use this mode, one need to modify some emulators to simulate scenario
> using the virtual clock and report some events using the virtual clock
> too.
> This kind of changes cannot be generic as the scenario will depend
> on the tested application, so modified emulators are not part of this
> patch set.

There should be no need to modify device models if you use "-rtc
clock=vm".  Or are there other cases besides RTC devices?

Paolo

Re: [Qemu-devel] [PATCH 0/3] implement a new icount_no_rt mode

[Victor Clement]

----- Mail original -----
> De: "Paolo Bonzini" <pbonzini@redhat.com>
> À: "Victor CLEMENT" <victor.clement@openwide.fr>, qemu-devel@nongnu.org
> Cc: "francois guerret" <francois.guerret@hotmail.fr>
> Envoyé: Mercredi 27 Mai 2015 14:52:55
> Objet: Re: [Qemu-devel] [PATCH 0/3] implement a new icount_no_rt mode
> 
> [...] Or are there other cases besides RTC devices?
> 
> Paolo
> 

For the normal use case of QEmu, No. But we want to use QEmu to test hard
real time application against simulated external stimuli.

So basically, Qemu will be used to run the embedded software, but
the external interfaces (GPIO, SPI, CAN bus...) will be controlled
by a basic simulator playing some predefined scenario.
Also we will record some traces to validate the behavior.

The scenario engine and the trace recorder will need to use the virtual
clock, so that all dates are based on the same clock.

Again, at this stage we think this scenario engine will not be generic
so the code will not be ready for integration in qemu.

Our goal is to be able to run a real time application (under an RTOS)
and test it with some scenario :
For instance our application could monitor a GPIO and send a specific
CAN frame within a specified delay.
In that case, the scenario will control the GPIO input and the recorder
will trace both the GPIO and the CAN bus. So by analysing the traces
we will be able to check that the software meets its timing constraints.

This example is simple but still shows the kind of problems we want to
solve.

I hope this enlighten you on our motivations.

Best regards,

Victor Clément & Julien Viard de Galbert

Re: [Qemu-devel] [PATCH 1/3] icount: implement a new icount_no_rt mode without real time cpu sleeping

[Victor Clement]

----- Mail original -----
> De: "Paolo Bonzini" <pbonzini@redhat.com>
> À: "Victor CLEMENT" <victor.clement@openwide.fr>, qemu-devel@nongnu.org
> Cc: "francois guerret" <francois.guerret@hotmail.fr>
> Envoyé: Mercredi 27 Mai 2015 14:52:00
> Objet: Re: [Qemu-devel] [PATCH 1/3] icount: implement a new icount_no_rt mode without real time cpu sleeping
> 
> 
> 
> On 27/05/2015 13:52, Victor CLEMENT wrote:
> > In this new icount_no_rt mode, the QEMU_VIRTUAL_CLOCK runs at the
> > maximum possible speed by warping the sleep times of the virtual
> > cpu to the
> > soonest clock deadline. The virtual clock will be updated only
> > according
> > the instruction counter.
> > 
> > Signed-off-by: Victor CLEMENT <victor.clement@openwide.fr>
> > ---
> >  cpus.c | 64
> >  ++++++++++++++++++++++++++++++++++++++++------------------------
> >  1 file changed, 40 insertions(+), 24 deletions(-)
> > 
> > diff --git a/cpus.c b/cpus.c
> > index de6469f..012d14b 100644
> > --- a/cpus.c
> > +++ b/cpus.c
> > @@ -105,6 +105,7 @@ static bool all_cpu_threads_idle(void)
> >  
> >  /* Protected by TimersState seqlock */
> >  
> > +static bool icount_no_rt;
> 
> It is somewhat hard to read the code due to double negations.  What
> about "-icount sleep=[yes|no]" and naming the variable
> "icount_sleep"?

You are right, the "nort" can be ambiguous. icount_sleep seems clear.
Thanks for the suggestion.

> [...]
> > +        if (icount_no_rt) {
> > +            /*
> > +             * We never let VCPUs sleep in async icount mode.
> 
> s/async icount/sleep=no/
> 
> ?

Right ! My bad...

> 
> Otherwise the series looks good.
> 
> Paolo

Ok, I sumbit the v2 with icount_sleep naming.

Victor

> 
> > +             * If there is a pending QEMU_CLOCK_VIRTUAL timer we
> > just advance
> > +             * to the next QEMU_CLOCK_VIRTUAL event and notify it.
> > +             * It is useful when we want a deterministic execution
> > time,
> > +             * isolated from host latencies.
> > +             */
> > +            seqlock_write_lock(&timers_state.vm_clock_seqlock);
> > +            timers_state.qemu_icount_bias += deadline;
> > +            seqlock_write_unlock(&timers_state.vm_clock_seqlock);
> > +            qemu_clock_notify(QEMU_CLOCK_VIRTUAL);
> > +        } else {
> > +            /*
> > +             * We do stop VCPUs and only advance
> > QEMU_CLOCK_VIRTUAL after some
> > +             * "real" time, (related to the time left until the
> > next event) has
> > +             * passed. The QEMU_CLOCK_VIRTUAL_RT clock will do
> > this.
> > +             * This avoids that the warps are visible externally;
> > for example,
> > +             * you will not be sending network packets
> > continuously instead of
> > +             * every 100ms.
> > +             */
> > +            seqlock_write_lock(&timers_state.vm_clock_seqlock);
> > +            if (vm_clock_warp_start == -1 || vm_clock_warp_start >
> > clock) {
> > +                vm_clock_warp_start = clock;
> > +            }
> > +            seqlock_write_unlock(&timers_state.vm_clock_seqlock);
> > +            timer_mod_anticipate(icount_warp_timer, clock +
> > deadline);
> >          }
> > -        seqlock_write_unlock(&timers_state.vm_clock_seqlock);
> > -        timer_mod_anticipate(icount_warp_timer, clock + deadline);
> >      } else if (deadline == 0) {
> >          qemu_clock_notify(QEMU_CLOCK_VIRTUAL);
> >      }
> > 
> 
>

Re: [Qemu-devel] [PATCH 0/3] implement a new icount_no_rt mode

[Paolo Bonzini]

On 29/05/2015 10:54, Victor Clement wrote:
> ----- Mail original -----
>> De: "Paolo Bonzini" <pbonzini@redhat.com>
>> À: "Victor CLEMENT" <victor.clement@openwide.fr>, qemu-devel@nongnu.org
>> Cc: "francois guerret" <francois.guerret@hotmail.fr>
>> Envoyé: Mercredi 27 Mai 2015 14:52:55
>> Objet: Re: [Qemu-devel] [PATCH 0/3] implement a new icount_no_rt mode
>>
>> [...] Or are there other cases besides RTC devices?
> 
> The scenario engine and the trace recorder will need to use the virtual
> clock, so that all dates are based on the same clock.

Right, but there is no reason for these to use any other clock than the
virtual clock.

> I hope this enlighten you on our motivations.

I understood your motivations; I'm still not really sure what other
modifications you need in order to achieve determinism.

Paolo

Re: [Qemu-devel] [PATCH 0/3] implement a new icount_no_rt mode

[Victor Clement]

----- Mail original -----
> De: "Paolo Bonzini" <pbonzini@redhat.com>
> À: "Victor Clement" <victor.clement@openwide.fr>, qemu-devel@nongnu.org
> Cc: "françois Guerret" <francois.guerret@hotmail.fr>, "Julien Viard de Galbert" <julien.viarddegalbert@openwide.fr>
> Envoyé: Vendredi 29 Mai 2015 13:14:38
> Objet: Re: [Qemu-devel] [PATCH 0/3] implement a new icount_no_rt mode
> 
> 
> 
> On 29/05/2015 10:54, Victor Clement wrote:
> > ----- Mail original -----
> >> De: "Paolo Bonzini" <pbonzini@redhat.com>
> >> À: "Victor CLEMENT" <victor.clement@openwide.fr>,
> >> qemu-devel@nongnu.org
> >> Cc: "francois guerret" <francois.guerret@hotmail.fr>
> >> Envoyé: Mercredi 27 Mai 2015 14:52:55
> >> Objet: Re: [Qemu-devel] [PATCH 0/3] implement a new icount_no_rt
> >> mode
> >>
> >> [...] Or are there other cases besides RTC devices?
> > 
> > The scenario engine and the trace recorder will need to use the
> > virtual
> > clock, so that all dates are based on the same clock.
> 
> Right, but there is no reason for these to use any other clock than
> the
> virtual clock.
> 
> > I hope this enlighten you on our motivations.
> 
> I understood your motivations; I'm still not really sure what other
> modifications you need in order to achieve determinism.
> 
> Paolo
> 

Normally none for determinism.

The only modification we need for our use case is to add some interfaces with the scenario engine 
and the trace recorder.

Victor