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 -- Aleksandr Bezzubikov
