qemu-devel
[Top][All Lists]
Advanced

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

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


From: Ciro Santilli
Subject: Re: [Qemu-devel] [RFC PATCH v6 00/20] replay additions
Date: Tue, 20 Feb 2018 23:59:39 +0000

On Tue, Feb 20, 2018 at 9:46 AM, Pavel Dovgalyuk <address@hidden> wrote:
>> From: Ciro Santilli [mailto:address@hidden
>> On Mon, Feb 19, 2018 at 8:02 AM, Pavel Dovgalyuk <address@hidden> wrote:
>> >> From: Pavel Dovgalyuk [mailto:address@hidden
>> >> > 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.
>> >> >
>> >> > 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...
>> >>
>> >> Peter, I bisected this bug and figured out the following.
>> >>
>> >> icount in ARM was broken by the following commit: 
>> >> 9b990ee5a3cc6aa38f81266fb0c6ef37a36c45b9
>> >> tcg: Add CPUState cflags_next_tb
>> >> This commit breaks execution of Ciro's kernel with enabled icount.
>> >> I haven't yet figured out why this happens.
>> >
>> > The problem is in the following code.
>> > As far, as I can understand, original version recompiles the TB and
>> > continues the execution as it goes.
>> >
>> > But the modified version sets cflags for the next compilation.
>> > And these are the flags for the old TB which should replace the original 
>> > one.
>> > TCG tries to use cflags for the new TB (which starts after the interrupted 
>> > one)
>> > and fails, because these flags are inappropriate.
>> > That is why icount execution fails.
>> >
>> > New version also does not include recompilation of the old block, which is 
>> > wrong too.
>> >
>>
>> Awesome! Can you push it to a branch, and give the full qemu command
>> line so I can test it?
>
> Updated the branch on github.
> You may try it.
>

Thanks,

At 8a482834780a131e7747c1c3c1931379ed0beedc ARM initrd record runs,
but replay is getting stuck at:

[   12.120424] scsi host0: sym-2.2.3

Neighboring lines on record:

[   11.346357] sym53c8xx 0000:00:0c.0: enabling device (0100 -> 0103)
[   11.536683] sym0: <895a> rev 0x0 at pci 0000:00:0c.0 irq 66
[   11.731679] sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking
[   11.930599] sym0: SCSI BUS has been reset.
[   12.120424] scsi host0: sym-2.2.3
[   15.451809] scsi 0:0:2:0: CD-ROM            QEMU     QEMU CD-ROM
  2.5+ PQ: 0 ANSI: 5
[   15.847227] scsi target0:0:2: tagged command queuing enabled,
command queue depth 16.
[   16.256585] scsi target0:0:2: Beginning Domain Validation
[   16.482189] scsi target0:0:2: Domain Validation skipping write tests
[   16.699445] scsi target0:0:2: Ending Domain Validation

My QEMU command:

time ./buildroot/output.arm~/host/usr/bin/qemu-system-arm -M
versatilepb -append 'root=/dev/sda nokaslr norandmaps
printk.devkmsg=on printk.time=y - lkmc_eval="/rand_check.out;wget -S
google.com;/poweroff.out;"'
 -kernel ./buildroot/output.arm~/images/zImage -dtb
./buildroot/output.arm~/images/versatile-pb.dtb -nographic -initrd
./buildroot/output.arm~/images/rootfs.cpio -netdev user,id=net1
-device rtl8139,netdev=net1
-object filter-replay,id=replay,netdev=net1

What is your full QEMU command?

Also I think the patch to fix qmeu-img was not included in the branch.

> Pavel Dovgalyuk
>



reply via email to

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