Re: [Qemu-devel] [RFC PATCH v7 15/21] replay: checkpoints
From: Paolo Bonzini [mailto:pbonz...@redhat.com] On 13/01/2015 10:15, Pavel Dovgaluk wrote: The numbers have no meaning. They just have to be distinct in different places. This is easier to achieve if you give a name to each place. Sorry, missed one thing. run_all is used to distinguish timers processed in AIO by calling of timerlistgroup_run_timers function and in main loop by calling qemu_clock_run_all_timers. Should you instead distinguish which TimerListGroup is being run? Then main loop would checkpoint once for every TimerListGroup (which means twice). I checked that. We should distinguish only run_all_timers and all other calls. Distinguishing the TimerListGroups does not work - replay hangs. Pavel Dovgalyuk
Re: [Qemu-devel] [RFC PATCH v7 15/21] replay: checkpoints
From: Paolo Bonzini [mailto:pbonz...@redhat.com]
On 12/01/2015 13:01, Pavel Dovgalyuk wrote:
+default:
+case QEMU_CLOCK_VIRTUAL:
+if ((replay_mode != REPLAY_MODE_NONE !runstate_is_running())
+|| !replay_checkpoint(run_all ? 2 : 3)) {
+return false;
+}
+break;
Please document the meaning of the numbers by making an enum.
The numbers have no meaning. They just have to be distinct in different places.
Why do you have to distinguish run_all?
It seems to be early versions artifact. I'll remove it.
Pavel Dovgalyuk
Re: [Qemu-devel] [RFC PATCH v7 15/21] replay: checkpoints
From: Pavel Dovgaluk [mailto:pavel.dovga...@ispras.ru]
From: Paolo Bonzini [mailto:pbonz...@redhat.com]
On 12/01/2015 13:01, Pavel Dovgalyuk wrote:
+default:
+case QEMU_CLOCK_VIRTUAL:
+if ((replay_mode != REPLAY_MODE_NONE !runstate_is_running())
+|| !replay_checkpoint(run_all ? 2 : 3)) {
+return false;
+}
+break;
Please document the meaning of the numbers by making an enum.
The numbers have no meaning. They just have to be distinct in different
places.
Why do you have to distinguish run_all?
It seems to be early versions artifact. I'll remove it.
Sorry, missed one thing.
run_all is used to distinguish timers processed in AIO by calling of
timerlistgroup_run_timers function
and in main loop by calling qemu_clock_run_all_timers.
We need to distinguish that to secure the sequence of the events.
It makes sense when we use checkpointing while recording the execution.
Pavel Dovgalyuk
Re: [Qemu-devel] [RFC PATCH v7 15/21] replay: checkpoints
On 13/01/2015 15:26, Pavel Dovgaluk wrote: Should you instead distinguish which TimerListGroup is being run? Then main loop would checkpoint once for every TimerListGroup (which means twice). Then I'll have to introduce some kind of deterministic ID for them and new asynchronous event to be saved instead of common checkpoints. Because these calls can be invoked in any order. But I have no idea of how to make such a deterministic ID. There is currently one TimerListGroup per iothread object, and two more. You can start by not supporting iothreads, or you can give a deterministic ID to iothreads. Paolo
Re: [Qemu-devel] [RFC PATCH v7 15/21] replay: checkpoints
On 13/01/2015 15:26, Pavel Dovgaluk wrote: Should you instead distinguish which TimerListGroup is being run? Then main loop would checkpoint once for every TimerListGroup (which means twice). Then I'll have to introduce some kind of deterministic ID for them and new asynchronous event to be saved instead of common checkpoints. Because these calls can be invoked in any order. But I have no idea of how to make such a deterministic ID. There is currently one TimerListGroup per iothread object, and two more. You can start by not supporting iothreads, or you can give a deterministic ID to iothreads. Thread pools are similar to TimerListGroups, except there is only one global pool instead of two. Paolo
Re: [Qemu-devel] [RFC PATCH v7 15/21] replay: checkpoints
From: Paolo Bonzini [mailto:pbonz...@redhat.com] On 13/01/2015 10:15, Pavel Dovgaluk wrote: The numbers have no meaning. They just have to be distinct in different places. This is easier to achieve if you give a name to each place. Sorry, missed one thing. run_all is used to distinguish timers processed in AIO by calling of timerlistgroup_run_timers function and in main loop by calling qemu_clock_run_all_timers. Should you instead distinguish which TimerListGroup is being run? Then main loop would checkpoint once for every TimerListGroup (which means twice). Then I'll have to introduce some kind of deterministic ID for them and new asynchronous event to be saved instead of common checkpoints. Because these calls can be invoked in any order. But I have no idea of how to make such a deterministic ID. Pavel Dovgalyuk
Re: [Qemu-devel] [RFC PATCH v7 15/21] replay: checkpoints
On 13/01/2015 10:15, Pavel Dovgaluk wrote: The numbers have no meaning. They just have to be distinct in different places. This is easier to achieve if you give a name to each place. Sorry, missed one thing. run_all is used to distinguish timers processed in AIO by calling of timerlistgroup_run_timers function and in main loop by calling qemu_clock_run_all_timers. Should you instead distinguish which TimerListGroup is being run? Then main loop would checkpoint once for every TimerListGroup (which means twice). We need to distinguish that to secure the sequence of the events. It makes sense when we use checkpointing while recording the execution. I see. Paolo
Re: [Qemu-devel] [RFC PATCH v7 15/21] replay: checkpoints
On 12/01/2015 13:01, Pavel Dovgalyuk wrote:
+default:
+case QEMU_CLOCK_VIRTUAL:
+if ((replay_mode != REPLAY_MODE_NONE !runstate_is_running())
+|| !replay_checkpoint(run_all ? 2 : 3)) {
+return false;
+}
+break;
Please document the meaning of the numbers by making an enum. Why do
you have to distinguish run_all?
Paolo
