[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 4/4] events doubts
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH 4/4] events doubts |
Date: |
Wed, 7 Oct 2015 12:23:38 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 |
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
- [Qemu-devel] [RFH PATCH 0/4] record/replay fixups and doubts, Paolo Bonzini, 2015/10/08
- [Qemu-devel] [PATCH 4/4] events doubts, Paolo Bonzini, 2015/10/08
- Re: [Qemu-devel] [PATCH 4/4] events doubts, Pavel Dovgaluk, 2015/10/08
- Message not available
- Re: [Qemu-devel] [PATCH 4/4] events doubts, Paolo Bonzini, 2015/10/08
- Re: [Qemu-devel] [PATCH 4/4] events doubts, Pavel Dovgaluk, 2015/10/08
- Re: [Qemu-devel] [PATCH 4/4] events doubts,
Paolo Bonzini <=
- Re: [Qemu-devel] [PATCH 4/4] events doubts, Pavel Dovgaluk, 2015/10/08
- Re: [Qemu-devel] [PATCH 4/4] events doubts, Paolo Bonzini, 2015/10/08
- Re: [Qemu-devel] [PATCH 4/4] events doubts, Pavel Dovgaluk, 2015/10/08
- Re: [Qemu-devel] [PATCH 4/4] events doubts, Paolo Bonzini, 2015/10/08
[Qemu-devel] [PATCH 1/4] replay: generalize ptimer event to bottom halves, Paolo Bonzini, 2015/10/08
[Qemu-devel] [PATCH 3/4] why is runstate_is_running needed?, Paolo Bonzini, 2015/10/08