[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH v6 00/20] replay additions
From: |
Pavel Dovgalyuk |
Subject: |
Re: [Qemu-devel] [RFC PATCH v6 00/20] replay additions |
Date: |
Tue, 20 Feb 2018 12:46:25 +0300 |
> 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.
Pavel Dovgalyuk
- Re: [Qemu-devel] [RFC PATCH v6 00/20] replay additions, (continued)
- Re: [Qemu-devel] [RFC PATCH v6 00/20] replay additions, Ciro Santilli, 2018/02/13
- Re: [Qemu-devel] [RFC PATCH v6 00/20] replay additions, Pavel Dovgalyuk, 2018/02/13
- Re: [Qemu-devel] [RFC PATCH v6 00/20] replay additions, Pavel Dovgalyuk, 2018/02/13
- Re: [Qemu-devel] [RFC PATCH v6 00/20] replay additions, Peter Maydell, 2018/02/13
- Re: [Qemu-devel] [RFC PATCH v6 00/20] replay additions, Pavel Dovgalyuk, 2018/02/13
- Re: [Qemu-devel] [RFC PATCH v6 00/20] replay additions, Ciro Santilli, 2018/02/13
- Re: [Qemu-devel] [RFC PATCH v6 00/20] replay additions, Pavel Dovgalyuk, 2018/02/13
- Re: [Qemu-devel] [RFC PATCH v6 00/20] replay additions, Pavel Dovgalyuk, 2018/02/14
- Re: [Qemu-devel] [RFC PATCH v6 00/20] replay additions, Pavel Dovgalyuk, 2018/02/19
- Re: [Qemu-devel] [RFC PATCH v6 00/20] replay additions, Ciro Santilli, 2018/02/19
- Re: [Qemu-devel] [RFC PATCH v6 00/20] replay additions,
Pavel Dovgalyuk <=
- Re: [Qemu-devel] [RFC PATCH v6 00/20] replay additions, Ciro Santilli, 2018/02/20
- Re: [Qemu-devel] [RFC PATCH v6 00/20] replay additions, Pavel Dovgalyuk, 2018/02/21
- Re: [Qemu-devel] [RFC PATCH v6 00/20] replay additions, Ciro Santilli, 2018/02/21
- Re: [Qemu-devel] [RFC PATCH v6 00/20] replay additions, Pavel Dovgalyuk, 2018/02/22
- Re: [Qemu-devel] [RFC PATCH v6 00/20] replay additions, Pavel Dovgalyuk, 2018/02/22
- Re: [Qemu-devel] [RFC PATCH v6 00/20] replay additions, Ciro Santilli, 2018/02/22
- Re: [Qemu-devel] [RFC PATCH v6 00/20] replay additions, Pavel Dovgalyuk, 2018/02/12
- Re: [Qemu-devel] [RFC PATCH v6 00/20] replay additions, Ciro Santilli, 2018/02/14
- Re: [Qemu-devel] [RFC PATCH v6 00/20] replay additions, Pavel Dovgalyuk, 2018/02/14
Re: [Qemu-devel] [RFC PATCH v6 00/20] replay additions, no-reply, 2018/02/07