From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55772) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzpjE-0008QO-8M for qemu-devel@nongnu.org; Thu, 18 Jul 2013 11:02:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uzpj9-0004CL-DV for qemu-devel@nongnu.org; Thu, 18 Jul 2013 11:02:48 -0400 Received: from [2001:41d0:8:2b42::1] (port=45585 helo=ns232118.ovh.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uzpj9-0004Bw-73 for qemu-devel@nongnu.org; Thu, 18 Jul 2013 11:02:43 -0400 From: fred.konrad@greensocs.com Date: Thu, 18 Jul 2013 17:02:34 +0200 Message-Id: <1374159757-16383-1-git-send-email-fred.konrad@greensocs.com> Subject: [Qemu-devel] [RFC 0/3] Determinitic behaviour with icount. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: pbonzini@redhat.com, mark.burton@greensocs.com, fred.konrad@greensocs.com From: KONRAD Frederic 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