From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:36677)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1Ucc2K-0006xk-WD
	for qemu-devel@nongnu.org; Wed, 15 May 2013 09:46:35 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1Ucc2G-0000zm-BU
	for qemu-devel@nongnu.org; Wed, 15 May 2013 09:46:32 -0400
Received: from mx1.redhat.com ([209.132.183.28]:51744)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1Ucc2G-0000zi-2A
	for qemu-devel@nongnu.org; Wed, 15 May 2013 09:46:28 -0400
Message-ID: <519391AB.8030603@redhat.com>
Date: Wed, 15 May 2013 15:46:19 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <51935609.4020705@greensocs.com> <5193849D.4070408@redhat.com>
	<51938F05.8060203@greensocs.com>
In-Reply-To: <51938F05.8060203@greensocs.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [RFC] save/restore with icount enabled.
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: =?ISO-8859-1?Q?KONRAD_Fr=E9d=E9ric?= <fred.konrad@greensocs.com>
Cc: Mark Burton <mark.burton@greensocs.com>, qemu-devel <qemu-devel@nongnu.org>

Il 15/05/2013 15:35, KONRAD Fr=E9d=E9ric ha scritto:
> On 15/05/2013 14:50, Paolo Bonzini wrote:
>> Il 15/05/2013 11:31, KONRAD Fr=E9d=E9ric ha scritto:
>>> Hi,
>>>
>>> We are trying to do a simple save/restore on the VM with icount enabl=
ed.
>>>
>>> We saw that qemu_icount_bias and qemu_icount in cpus.c are not
>>> saved/restored,
>>> and icount_extra, icount_decr in CPUState neither, so the vm_clock is
>>> just
>>> growing normally after restoring the VM is that normal?
>>>
>>> We think that this is making the "replay" undeterminastic, which is
>>> bad for
>>> reverse execution.
>>>
>>> Is there a good reason for them not being saved?
>> No.  You can probably move icount to timers_state.  Something like
>> zeroing qemu_icount in cpu_disable_ticks() is required in order to sav=
e
>> qemu_icount_bias like the other members of timers_state.  There is eve=
n
>> a dummy field that you can reuse to avoid the pain of adding a
>> subsection to vmstate_timers. :)
>>
>> Paolo
>=20
> Yes nice point :).
>=20
> What about icount_extra and icount_decr defined in CPU_COMMON? in
> cpu-defs.h?
>=20
>     int64_t icount_extra; /* Instructions until next timer event. */   =
\
>     /* Number of cycles left, with interrupt flag in high bit.         =
 \
>        This allows a single read-compare-cbranch-write sequence to test=
 \
>        for both decrementer underflow and exceptions. */               =
\
>     union {                                                            =
 \
>         uint32_t u32;                                                  =
 \
>         icount_decr_u16 u16;                                           =
 \
>     } icount_decr;                                                     =
 \

I'm not sure, I don't know that part well.  But IIRC they are recomputed
every time the VM restarts, so you don't need to save them?

Paolo