Re: [Qemu-devel] [RFC PATCH v6 00/20] replay additions

[Ciro Santilli]

On Tue, Feb 13, 2018 at 10:52 AM, Pavel Dovgalyuk <address@hidden>
wrote:

> > From: Peter Maydell [mailto:address@hidden
> > On 13 February 2018 at 10:26, Pavel Dovgalyuk <address@hidden>
> 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
>
>