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

[Alexander Bezzubikov <abezzubikov@ispras.ru>]

Alex Bennée писал 2017-09-19 17:25:
> Aleksandr Bezzubikov <zuban32s@gmail.com> writes:
> 
>> 2017-09-19 12:30 GMT+03:00 Alex Bennée <alex.bennee@linaro.org>:
>>> 
>>> Pavel Dovgalyuk <dovgaluk@ispras.ru> writes:
>>> 
>>>>> From: Aleksandr Bezzubikov [mailto:zuban32s@gmail.com]
>>>>> 2017-09-18 15:02 GMT+03:00 Aleksandr Bezzubikov 
>>>>> <zuban32s@gmail.com>:
>>>>> > 2017-05-02 15:42 GMT+03:00 Igor R <boost.lists@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?

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