Aleksandr Bezzubikov <zuban...@gmail.com> writes: > 2017-09-19 12:30 GMT+03:00 Alex Bennée <alex.ben...@linaro.org>: >> >> Pavel Dovgalyuk <dovga...@ispras.ru> writes: >> >>>> From: Aleksandr Bezzubikov [mailto:zuban...@gmail.com] >>>> 2017-09-18 15:02 GMT+03:00 Aleksandr Bezzubikov <zuban...@gmail.com>: >>>> > 2017-05-02 15:42 GMT+03:00 Igor R <boost.li...@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
