qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v3 09/15] replay: implement replay-seek command


From: Pavel Dovgalyuk
Subject: Re: [PATCH v3 09/15] replay: implement replay-seek command
Date: Tue, 8 Sep 2020 15:15:30 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

On 08.09.2020 14:10, Alex Bennée wrote:

Alex Bennée <alex.bennee@linaro.org> writes:

Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru> writes:

On 07.09.2020 19:25, Alex Bennée wrote:

Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru> writes:

On 07.09.2020 17:59, Alex Bennée wrote:

Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru> writes:

On 07.09.2020 15:58, Alex Bennée wrote:

Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru> writes:

From: Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>

This patch adds hmp/qmp commands replay_seek/replay-seek that proceed
the execution to the specified instruction count.
The command automatically loads nearest snapshot and replays the execution
to find the desired instruction count.

Should there be an initial snapshot created at instruction 0? Using a
separate monitor channel:

Right, you can't go to the prior state, when there is no preceding
snapshot available.

It seems creating an initial snapshot automatically would be more user

Please take a look at 'Snapshotting' section of docs/replay.txt.
Reverse debugging is considered to be run with disk image (overlay)
and rrsnapshot option of icount, which allows creating an initial
VM snapshot.

Given that I'm using the block device purely for VM snapshots I think it
would be useful to document the minimal "no disk" approach - i.e. where
the disk is only used for record/replay.

However I'm still having trouble. I can record the trace with:

    ./qemu-system-aarch64 -cpu cortex-a53 -display none -serial stdio \
      -machine virt -kernel zephyr.elf -net none \
      -icount 
shift=6,align=off,sleep=off,rr=record,rrfile=record.out,rrsnapshot=rrstart  \
      -drive file=record.qcow2,if=none,id=rr \
      -monitor telnet:127.0.0.1:4444 -S

Can you provide your zephyr.elf image?


which shows:

    (qemu) info snapshots
    info snapshots
    List of snapshots present on all disks:
    ID        TAG               VM SIZE                DATE     VM CLOCK     
ICOUNT
    --        rrstart           653 KiB 2020-09-07 17:12:42 00:00:00.000        
  0

but do I need a whole separate overlay in the replay case? I thought
supplying snapshot to the drive would prevent the replay case
overwriting what has been recorded but with:

      -icount shift=6,align=off,sleep=off,rr=replay,rrfile=record.out \
      -drive file=record.qcow2,if=none,id=rr,snapshot

When you provide qcow2 (overlay or not) for snapshotting, you don't need
any 'snapshot' option on drive.


but I get:

    (qemu) info snapshots
    info snapshots
    There is no snapshot available.

so if I drop the ,snapshot from the line I can at least see the snapshot
but continue doesn't seem to work:

    (qemu) info snapshots
    info snapshots
    List of snapshots present on all disks:
    ID        TAG               VM SIZE                DATE     VM CLOCK     
ICOUNT
    --        rrstart           653 KiB 2020-09-07 17:12:42 00:00:00.000        
  0
    (qemu) replay_break 190505
    replay_break 190505
    (qemu) c
    c
    (qemu) info replay
    info replay
    Replaying execution 'record.out': instruction count = 0

It seems, that replay hangs. Can you try removing '-S' in record command
line?

That doesn't make any difference removing from both the record and
replay cases. It seems to need a loadvm to start things off.

I've sent you an image off list. Please let me know if you can
replicate.

OK I can successfully use gdb to reverse debug the acceptance test (\o/)
so I suspect there are differences in the calling setup.

The first one is ensuring that rrsnapshot is set for both record and
replay. For this reason I think a more user friendly automatic snapshot
would be worth setting up when record/replay is being used.

-icount sleep=off definitely breaks things. Do we keep track of the

It was ok for me:
qemu-system-aarch64 -cpu cortex-a53 -display none -serial stdio \
 -machine virt -kernel zephyr-64.elf -net none \
-icount shift=6,align=off,sleep=off,rr=replay,rrfile=record.out,rrsnapshot=rrstart \
 -drive file=record.qcow2,if=none,id=rr -s -S

  icount bias as save and restore state?


I don't know anything about sleep, but qemu_icount_bias is saved in vmstate when icount is enabled.

However, I noticed a strange condition at cpus.c:855
Shouldn't we check !sleep here instead of !icount_sleep?

    } else if (!icount_sleep) {
        error_setg(errp, "shift=auto and sleep=off are incompatible");
        return;
    }

    icount_sleep = sleep;





reply via email to

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