> From: Alex Bennée [mailto:alex.ben...@linaro.org] > Pavel Dovgalyuk <dovga...@ispras.ru> writes: > > >> From: Alex Bennée [mailto:alex.ben...@linaro.org] > >> Pavel Dovgalyuk <dovga...@ispras.ru> writes: > >> > >> >> From: Alex Bennée [mailto:alex.ben...@linaro.org] > >> >> Pavel Dovgalyuk <pavel.dovga...@ispras.ru> writes: > >> >> > >> >> > Ping? > >> >> > >> >> I started having a look but I ran into this straight away. First I > >> >> recorded a boot of the kernel: > >> >> > >> >> ./aarch64-softmmu/qemu-system-aarch64 -machine virt,graphics=on,gic- > >> >> version=3,virtualization=on -cpu cortex-a53 --serial mon:stdio -display > >> >> none -kernel > >> >> ../images/aarch64-current-linux-initrd-guest.img -icount > >> shift=7,rr=record,rrfile=replay.bin > >> >> > >> >> Then played back: > >> >> > >> >> ./aarch64-softmmu/qemu-system-aarch64 -machine virt,graphics=on,gic- > >> >> version=3,virtualization=on -cpu cortex-a53 --serial mon:stdio -display > >> >> none -kernel > >> >> ../images/aarch64-current-linux-initrd-guest.img -icount > >> shift=7,rr=replay,rrfile=replay.bin - > >> >> s -S > >> > > >> > This looks ok, but... > >> > > >> >> And did the following on gdb: > >> >> > >> >> (gdb) i > >> >> 0x0000000040000004 in ?? () > >> >> => 0x40000004: mov x1, xzr > >> >> 0x40000008: mov x2, xzr > >> >> 0x4000000c: mov x3, xzr > >> >> (gdb) > >> >> 0x0000000040000008 in ?? () > >> >> => 0x40000008: mov x2, xzr > >> >> 0x4000000c: mov x3, xzr > >> >> 0x40000010: ldr x4, 0x40000020 > >> >> (gdb) > >> >> 0x000000004000000c in ?? () > >> >> => 0x4000000c: mov x3, xzr > >> >> 0x40000010: ldr x4, 0x40000020 > >> >> 0x40000014: br x4 > >> >> (gdb) > >> >> 0x0000000040000010 in ?? () > >> >> => 0x40000010: ldr x4, 0x40000020 > >> >> 0x40000014: br x4 > >> >> 0x40000018: .inst 0x44000000 ; undefined > >> >> (gdb) > >> >> 0x0000000040000014 in ?? () > >> >> => 0x40000014: br x4 > >> >> 0x40000018: .inst 0x44000000 ; undefined > >> >> 0x4000001c: .inst 0x00000000 ; undefined > >> >> (gdb) p/x $x4 > >> >> $1 = 0x40080000 > >> >> (gdb) reverse-stepi > >> >> warning: Remote failure reply: E14 > >> >> > >> >> Surely this is the simple case and doesn't require any snapshots for > >> >> block devices as there are none. Am I missing something? > >> > > >> > Reverse debugging requires the snapshotting. QEMU can't revert the VM > >> > state without the > >> snapshots. > >> > You can try adding an empty qcow2 image to allow snapshotting there. > >> > >> I suspect a recent patch has broken locking again: > >> > >> Starting program: > >> /home/alex/lsrc/qemu/qemu.git/aarch64-softmmu/qemu-system-aarch64 - > machine > >> virt,graphics=on,gic-version=3,virtualization=on -cpu cortex-a53 --serial > >> mon:stdio - > display > >> none -kernel ../images/aarch64-current-linux-initrd-guest.img -icount > >> shift=7,rr=replay,rrfile=replay.bin,rrsnapshot=debug -drive > >> file=rr.qcow2,if=none,snapshot,id=rr -s -S
Just noticed. If you are using VM snapshots, then you should disable "snapshot" option of the drive. Like that: -drive file=rr.qcow2,if=none BTW, similar command line for aarch64 worked for me. I just removed "-display=none" for convenience. Pavel Dovgalyuk
