|
| From: | KONRAD Frédéric |
| Subject: | Re: [Qemu-devel] [RFC] save/restore with icount enabled. |
| Date: | Wed, 15 May 2013 15:35:01 +0200 |
| User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 |
On 15/05/2013 14:50, Paolo Bonzini wrote:
Il 15/05/2013 11:31, KONRAD Frédéric ha scritto:Hi, We are trying to do a simple save/restore on the VM with icount enabled. 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 save qemu_icount_bias like the other members of timers_state. There is even a dummy field that you can reuse to avoid the pain of adding a subsection to vmstate_timers. :) Paolo
Yes nice point :).What about icount_extra and icount_decr defined in CPU_COMMON? in cpu-defs.h?
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; \
Thanks,
Fred
Thanks, Fred
| [Prev in Thread] | Current Thread | [Next in Thread] |