Re: [Qemu-devel] What is the best commit for record-replay?

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

Aleksandr Bezzubikov <zuban32s@gmail.com> writes:

> 2017-09-19 12:30 GMT+03:00 Alex Bennée <alex.bennee@linaro.org>:
>>
>> Pavel Dovgalyuk <dovgaluk@ispras.ru> writes:
>>
>>>> From: Aleksandr Bezzubikov [mailto:zuban32s@gmail.com]
>>>> 2017-09-18 15:02 GMT+03:00 Aleksandr Bezzubikov <zuban32s@gmail.com>:
>>>> > 2017-05-02 15:42 GMT+03:00 Igor R <boost.lists@gmail.com>:
>>>> >>>>>> I'm trying to use the deterministic record/replay feature, and I would
>>>> >>>>>> like to know which commit I should take to get it work.
>>>> >>>>>> In RC0 it seems to be broken. I tried pre-MTTCG commit 2421f381dc, as
>>>> >>>>
>>>> >>>>> Can you retry with the latest rc? There were some fixes regarding rr since rc0.
>>>> >>>>
>>>> >>>>
>>>> >>>> I've taken 2.9 release, and RR does not seem to work there.
>>>> >>>> I recorded the boot process of x86 Fedora-21 linux and the replay got
>>>> >>>> stuck almost immediately.
>>>> >>>
>>>> >>> What's your command line?
>>>> >>>
>>>> >>> Does it get stuck at the same place each time?
>>>> >>>
>>>> >>> Can you boot fine with icount but without record/replay?
>>>> >>
>>>> >> Here is the exact scenario:
>>>> >> - Get 2.9 from git, configure it as follows: "./configure
>>>> >> --target-list=i386-softmmu --enable-sdl" and  make.
>>>> >> - Download https://people.debian.org/~aurel32/qemu/i386/debian_squeeze_i386_standard.qcow2
>>>> >> - Run qemu with the following command line, until login prompt:
>>>> >> -icount shift=7,rr=record,rrfile=replay.bin -drive
>>>> >> file=debian_squeeze_i386_standard.qcow2,if=none,id=img-direct -drive
>>>> >> driver=blkreplay,if=none,image=img-direct,id=img-blkreplay -device
>>>> >> ide-hd,drive=img-blkreplay -monitor stdio
>>>> >> - Replay: -icount shift=7,rr=replay,rrfile=replay.bin -drive
>>>> >> file=debian_squeeze_i386_standard.qcow2,if=none,id=img-direct -drive
>>>> >> driver=blkreplay,if=none,image=img-direct,id=img-blkreplay -device
>>>> >> ide-hd,drive=img-blkreplay -monitor stdio
>>>> >>
>>>> >> Every time I attempt to replay, QEMU gets stuck at the same EIP, at a
>>>> >> very early stage.
>>>> >>
>>>> >>
>>>> >>> Can you boot fine with icount but without record/replay?
>>>> >>
>>>> >> Yes. I can also enable icount and recording - it also boots fine. The
>>>> >> problem with the replay.
>>>> >
>>>> > Hi guys,
>>>> > Maybe the thread is a bit outdated, but the problem is still relevant.
>>>> > I've just tried to record and replay WinXP boot process, and I've encountered
>>>> > exactly the same problem as described above - record is fine, replay
>>>> > gets stuck early. I use current master.
>>>
>>> Maybe this commit will work: cfb2d02be9413d45b30ed6d8e38800250b6b4b48
>
> Unfortunately this one doesn't work either. It seems we need just an
> all-in-one fix
> for the current implementation to make it work.
>
>>>
>>>> > And I've discovered the second problem - recording makes initial snapshot,
>>>> > but it doesn't seem to be saved to the disk - replay can't see it.
>>>
>>> It is ok, because there is a mode where snapshot is created and loaded.
>
> So it shouldn't work properly when I use 'rrsnapshot=<name>' for both
> record and replay?
> Then how can I enable this mode?
>
>>>
>>>> >
>>>> > Hope you've already found the solution (as the last post was on 2 May)
>>>> > and it's just got missed the mailing list.
>>>
>>> As I know, RR is still broken in the current version.
>>> It was caused by the MTTCG implementation.
>>> Alex Bennee tried to fix RR back. Alex, have you found any solution?
>>>
>>> We also trying to find a way to fix RR. It seems, that we will reinvent BQL for RR.
>>
>> I think the method outlined in my RFC is the way to go, essentially the
>> RR mutex taking over for the what the BQL did. The RFC patch hadn't
>> hoisted the mutex for the additional devices so I'm just re-basing now
>> and I'll see if I can make the changes for Igor's test case.
>>
>> --
>> Alex Bennée

Could you try:

  https://github.com/stsquad/qemu/tree/bql-and-replay-locks-v2

And report back?

--
Alex Bennée