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) >>> - 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