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

[Alexander Bezzubikov]

Alex Bennée писал 2017-09-19 17:25:
> Aleksandr Bezzubikov <address@hidden> writes:
>
> > 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
>
> Could you try:
>
>   https://github.com/stsquad/qemu/tree/bql-and-replay-locks-v2
>
> And report back?

I've encountered 2 new things:
1) Significant performance regression during recording
2) Sometimes I can get through BIOS to the OS boot process itself
   Previously it got stuck in BIOS, the last block I had (I mean with -d 
in_asm) was

    IN:
    0x0000000000007ef6:  pushfl
    0x0000000000007ef8:  pushal
    0x0000000000007efa:  mov    $0xe,%ah
    0x0000000000007efc:  xor    %bx,%bx
    0x0000000000007efe:  int    $0x10

   So I couldn't even get to the boot process of the OS itself.
   Now it passes to the OS unpredictably, and still not very far. 
Anyway, it doesn't
   reach the point I stopped recording.

So we have a little progress here.


> --
> Alex Bennée

--
Aleksandr Bezzubikov