Pavel Dovgalyuk <dovga...@ispras.ru> writes:
> On 19.05.2020 11:11, Alex Bennée wrote: >> Pavel Dovgalyuk <dovga...@ispras.ru> writes: >> >>> On 18.05.2020 18:56, Alex Bennée wrote: >>>> Philippe Mathieu-Daudé <phi...@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.dovga...@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". > > I've installed avocado and avocado-framework, but got the following error: > > venv/bin/python: No module named avocado Hmm make check-acceptance should automatically setup local copies of avocado using virtualenv. You shouldn't need to install the system version. > >> >>>> 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? > > Right. > > > Pavel Dovgalyuk -- Alex Bennée