[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Alexander Bezzubikov
Subject: Re: [Qemu-devel] What is the best commit for record-replay?
Date: Tue, 19 Sep 2017 18:46:48 +0300
User-agent: Roundcube Webmail/1.1.2

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 
>> - 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:


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

    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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]