On 07/10/2015 12:51, Pavel Dovgaluk wrote:
> > Why do they need to be separate on startup? Does initialization hang?
> > My reasoning was that QEMU_CLOCK_VIRTUAL is zero anyway at both init and
> > reset.
>
> I'm not sure about current (only core functions) version, but full version
> requires t
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> On 07/10/2015 10:21, Pavel Dovgaluk wrote:
> > There are two kinds of events:
> > - read from the log and injected immediately (user input, network input)
> > - read from the log and wait for corresponding event
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> On 07/10/2015 12:42, Pavel Dovgaluk wrote:
> >> > Ok, got it. I still want to understand exactly the need for the init
> >> > and reset checkpoints, and the placement of qemu_clock_warp calls, but
> >> > apart from that the patches are good to g
On 07/10/2015 12:42, Pavel Dovgaluk wrote:
>> > Ok, got it. I still want to understand exactly the need for the init
>> > and reset checkpoints, and the placement of qemu_clock_warp calls, but
>> > apart from that the patches are good to go for 2.5. Thanks for your
>> > persistence!
> Init chec
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> On 07/10/2015 11:50, Pavel Dovgaluk wrote:
> >> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> >> Bonzini
> >> On 07/10/2015 10:21, Pavel Dovgaluk wrote:
> >>> There are two kinds of events:
> >>> - read from the log a
On 07/10/2015 11:50, Pavel Dovgaluk wrote:
>> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
>> Bonzini
>> On 07/10/2015 10:21, Pavel Dovgaluk wrote:
>>> There are two kinds of events:
>>> - read from the log and injected immediately (user input, network input)
>>> - rea
On 07/10/2015 10:21, Pavel Dovgaluk wrote:
> There are two kinds of events:
> - read from the log and injected immediately (user input, network input)
> - read from the log and wait for corresponding event in the queue (BH)
>
> We cannot inject BH event immediately because we do not have any inf
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
>
> It is not clear what separates REPLAY_ASYNC_EVENT_BH from other async
> events. It seems to be an ordering issue, but then why do input events
> not have to be looked up in the queue? It would be much simple
It is not clear what separates REPLAY_ASYNC_EVENT_BH from other async
events. It seems to be an ordering issue, but then why do input events
not have to be looked up in the queue? It would be much simpler if they
are all handled the same way.
---
replay/replay-events.c | 7 ---
1 file change
