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

[Pavel Dovgalyuk]

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;