From: KONRAD Frederic <fred.kon...@greensocs.com>
Hi everybody,
As I said in the last email, we have issues with determinism with icount.
We are wondering if determinism is really ensured with icount?
We saw that the rt_clock is used at multiple place which is a pain for
replaying the simulation the same way. So we simply base rt_clock on icount.
When the cpu is idle vm_clock is synchronized with the host clock which is bad
for determinism, and this happen regularly in time even if there are no I/O.
We choose to synchronize vm_clock on the next event to make sure the vm will
restart, and to avoid non determinism.
Is this the right think to do?
An other issue:
A timer callback is triggered to make the snapshot regularly. Unfortunately this
was not at all regular. For example: if we use step function in GDB instead of
cont, the callback will be triggered more often.
So we :
* created a new clock (ic_clock) based only on icount without the bias.
* and we repaired icount_extra mechanism by computing it from ic_clock.
Then the snapshot are taken regularly with or without stepping in gdb, the timer
became accurate and call the callback at the exact ic_clock time.
Both icount and reverse execution need an instruction counter. icount use a
count-down mechanism but reverse execution need a continuous counter. For now
we have build a separate counter and we think that these two counters can be
merged. However we would like feedback about this before modifying this.
Adding these features has moved us forward, but - QEMU is STILL not
deterministic - we believe this is likely due to I/O which we will start
investigating next.
Fred
KONRAD Frederic (3):
icount: base rt_clock on icount.
icount: sync vm_clock on the next event.
icount: create a new icount based timer.
cpus.c | 21 +++++++++++++++++----
include/qemu/timer.h | 4 ++++
main-loop.c | 5 +++++
qemu-timer.c | 12 +++++++++++-
4 files changed, 37 insertions(+), 5 deletions(-)
--
1.8.1.4
