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

[Aleksandr Bezzubikov]

2017-09-19 12:30 GMT+03:00 Alex Bennée <address@hidden>:
>
> Pavel Dovgalyuk <address@hidden> writes:
>
>>> From: Aleksandr Bezzubikov [mailto:address@hidden
>>> 2017-09-18 15:02 GMT+03:00 Aleksandr Bezzubikov <address@hidden>:
>>> > 2017-05-02 15:42 GMT+03:00 Igor R <address@hidden>:
>>> >>>>>> 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



-- 
Aleksandr Bezzubikov