From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52277) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1duJTP-0004sZ-Lo for qemu-devel@nongnu.org; Tue, 19 Sep 2017 10:26:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1duJTM-0003cI-Vf for qemu-devel@nongnu.org; Tue, 19 Sep 2017 10:26:03 -0400 Received: from mail-wm0-x235.google.com ([2a00:1450:400c:c09::235]:47475) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1duJTM-0003az-KD for qemu-devel@nongnu.org; Tue, 19 Sep 2017 10:26:00 -0400 Received: by mail-wm0-x235.google.com with SMTP id 13so431660wmq.2 for ; Tue, 19 Sep 2017 07:25:59 -0700 (PDT) References: <87bmrj8eks.fsf@linaro.org> <000601d33128$2dd9d5e0$898d81a0$@ru> <87bmm7dohw.fsf@linaro.org> From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: Date: Tue, 19 Sep 2017 15:25:57 +0100 Message-ID: <878thaepe2.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] What is the best commit for record-replay? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Aleksandr Bezzubikov Cc: Pavel Dovgalyuk , QEMU Developers , Pranith Kumar , pavel.dovgaluk@ispras.ru, Aleksandr Bezzubikov , Paolo Bonzini , Igor R Aleksandr Bezzubikov writes: > 2017-09-19 12:30 GMT+03:00 Alex Bennée : >> >> Pavel Dovgalyuk writes: >> >>>> From: Aleksandr Bezzubikov [mailto:zuban32s@gmail.com] >>>> 2017-09-18 15:02 GMT+03:00 Aleksandr Bezzubikov : >>>> > 2017-05-02 15:42 GMT+03:00 Igor R : >>>> >>>>>> 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=' 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