Re: [PATCH] replay: synchronize on every virtual timer callback

["Alex Bennée" <alex.bennee@linaro.org>]

Pavel Dovgalyuk <dovgaluk@ispras.ru> writes:

> On 18.05.2020 18:56, Alex Bennée wrote:
>> Philippe Mathieu-Daudé <philmd@redhat.com> writes:
>>
>>> + Alex
>>>
>>> On 5/6/20 10:17 AM, Pavel Dovgalyuk wrote:
>>>> Sometimes virtual timer callbacks depend on order
>>>> of virtual timer processing and warping of virtual clock.
>>>> Therefore every callback should be logged to make replay deterministic.
>>>> This patch creates a checkpoint before every virtual timer callback.
>>>> With these checkpoints virtual timers processing and clock warping
>>>> events order is completely deterministic.
>>>> Signed-off-by: Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
>>>> ---
>>>>    util/qemu-timer.c |    5 +++++
>>>>    1 file changed, 5 insertions(+)
>>>> diff --git a/util/qemu-timer.c b/util/qemu-timer.c
>>>> index d548d3c1ad..47833f338f 100644
>>>> --- a/util/qemu-timer.c
>>>> +++ b/util/qemu-timer.c
>>>> @@ -588,6 +588,11 @@ bool timerlist_run_timers(QEMUTimerList *timer_list)
>>>>            qemu_mutex_lock(&timer_list->active_timers_lock);
>>>>              progress = true;
>>>> +        /*
>>>> +         * Callback may insert new checkpoints, therefore add new checkpoint
>>>> +         * for the virtual timers.
>>>> +         */
>>>> +        need_replay_checkpoint = timer_list->clock->type == QEMU_CLOCK_VIRTUAL;
>>>>        }
>>>>        qemu_mutex_unlock(&timer_list->active_timers_lock);
>> So the problem I have with this as with all the record/replay stuff I
>> need want to review is it's very hard to see things in action. I added a
>> *very* basic record/replay test to the aarch64 softmmu tests but they
>> won't exercise any of this code because no timers get fired. I'm
>> assuming the sort of tests that is really needed is something that not
>> only causes QEMU_CLOCK_VIRTUAL timers to fire and trigger logged HW
>> events and ensure that things don't get confused in the process.
>
> I encounter most of the bugs in different OS boot scenarios.
>
> We also have internal tests that include some computational, disk, and
> network interaction tasks.
>
> Is it possible to add a test like booting a "real" OS and replaying
> it?

Yes - for these bigger more complex setups we should use the acceptance
tests that run under Avocado. See "make check-acceptance".

>> If I read up the file I just get more questions than answers. For
>> example why do we release the qemu_timers lock before processing the
>> replay event? Is it that the replay event could cause another timer to
>
> We release the lock, because accessing the replay module may process
> some events and add more timers.

OK. I guess the adding of the timer is a side effect of processing the
event rather than something that gets added directly?

<snip>
-- 
Alex Bennée