Re: [Qemu-devel] [PATCH 4/4] events doubts

[Paolo Bonzini]

On 07/10/2015 11:50, Pavel Dovgaluk wrote:
>> From: Paolo Bonzini [mailto:address@hidden 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 in the queue (BH)
>>>
>>> We cannot inject BH event immediately because we do not have any information
>>> about callback
>>
>> Actually we do (indirectly, through aio_bh_call).  But that may not be
>> the central issue, because...
>>
>>> and to preserve consistency - BH cannot be processed before
>>> it is scheduled by qemu core.
>>
>> ... you are processing them differently anyway between record mode
>> (where the BH is scheduled by the core) and replay (where the BH is
>> called directly).
> 
> In record it also called through replay. It is scheduled into the replay
> events queue and called at checkpoint, where queue is flushed.
> 
>> In fact, I don't understand what introduces the difference between
>> record and replay that requires special handling of ptimers' bottom
>> halves.  In both cases, the ptimer triggers at the desired time (based
>> on checkpoints) and then the bottom half is called as soon as possible.
>>  Why is a separate async event necessary?
> 
> We want to preserve order of all events that affect virtual machine behavior,
> not only instructions execution. These events include processing of
> interrupts, exceptions, and bottom halves.
> That is why bottom halves are bind to checkpoints and recorded into the log.
> 
>> Because we only care about bottom halves from ptimers, their order
>> should be the same for both record and replay.
>>
>> If bottom halves async events could be removed, that would simplify a
>> lot the code, and it would make it a lot easier to understand for me.
> 
> I added ptimer handling because replay didn't work when I removed BH queuing.

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!

Paolo