I’ve tried starting QEMU with your files without SCSI at all. The problem is with implementation of icount in ARM.
The following command line fails with the same error: ./bin/qemu-system-arm -icount 7 -M versatilepb -nographic -dtb ./images/arm/versatile-pb.dtb -kernel ./images/arm/zImage -net none And it does not fail when I remove icount. Pavel Dovgalyuk From: Ciro Santilli [mailto:ciro.santi...@gmail.com] Sent: Tuesday, February 13, 2018 2:37 PM To: Pavel Dovgalyuk Cc: Peter Maydell; Pavel Dovgalyuk; QEMU Developers; Kevin Wolf; war2jor...@live.com; Igor R; Juan Quintela; Jason Wang; Michael S. Tsirkin; Aleksandr Bezzubikov; maria.klimushenk...@ispras.ru; Gerd Hoffmann; Thomas Dullien; Paolo Bonzini; Alex Bennée Subject: Re: [RFC PATCH v6 00/20] replay additions On Tue, Feb 13, 2018 at 10:52 AM, Pavel Dovgalyuk <dovga...@ispras.ru> wrote: > From: Peter Maydell [mailto:peter.mayd...@linaro.org] > On 13 February 2018 at 10:26, Pavel Dovgalyuk <dovga...@ispras.ru> wrote: > > Then I added SCSI adapter with the option –device lsi,id=scsi0 and QEMU > > failed with the following error: > > > > qemu: fatal: IO on conditional branch instruction > > > Seems, that your kernel is incomatible with QEMU, which ARM emulation is not > > good enough. Just to clarify, this is my working ARM command that works without record / replay: ./buildroot/output.arm~/host/usr/bin/qemu-system-arm -m 128M -monitor telnet::45454,server,nowait -netdev user,hostfwd=tcp::45455-:45455,id=net0 -smp 1 -M versatilepb -append 'root=/dev/sda nokaslr norandmaps printk.devkmsg=on printk.time=y' -device rtl8139,netdev=net0 -drive file=./buildroot/output.arm~/images/rootfs.ext2,if=scsi,format=raw -dtb ./buildroot/output.arm~/images/versatile-pb.dtb -kernel ./buildroot/output.arm~/images/zImage -serial stdio I then tried to modify it for record / replay to use similar options to the x86 version. The only non-trivial change was what to use for the drive. So I tried to replace them with: -drive file=./buildroot/output.arm~/images/rootfs.ext2,if=scsi,id=img-direct,format=raw \ -drive driver=blkreplay,if=none,image=img-direct,id=img-blkreplay \ -device scsi-hd,drive=img-blkreplay \ and some other variations, but this is just guesswork and likely to be wrong, since I don't understand those options very well. I don't need to use SCSI if that is not supported, I'd be happy with any record / replay QEMU command that works with the image I uploaded on the .zip. > > It seems fairly unlikely to me that the Linux driver for this > SCSI adaptor is using weirdo self-modifying code of the kind > that would trip up that cpu_abort(). I would suggest a bit > more investigation into what's actually happening... It happens for any SCSI adapter (i.e., for every system able to run). And the log is not very big. Therefore the problem is in early boot code. Pavel Dovgalyuk
