Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes

[Aleksandar Markovic]

On Sat, Jun 22, 2019 at 5:02 PM Mark Cave-Ayland
<address@hidden> wrote:
>
> On 22/06/2019 15:20, Mark Cave-Ayland wrote:
>
> > I've just given your tcg-ppc-vsx branch a spin here, and like Howard I'm 
> > getting
> > segfaults trying to launch my MacOS images :(  The segfault is weird: it 
> > doesn't get
> > caught by an attached gdb and the qemu-system-ppc process seems to hang 
> > around like a
> > zombie which makes me think that it's probably an illegal instruction of 
> > some kind,
> > but the PPC kernel can't handle it as well as x86 does.
> >
> > With a bit more work I bisected it down to the first commit in the patchset
> > (d8dcbb57e9: "tcg/ppc: Initial backend support for Altivec") and then as an
> > experiment I hacked tcg_can_emit_vec_op() to always return 0 to see if that 
> > made a
> > difference, but the segfault still appears.
> >
> > The commit message mentions that the load and store helpers are also 
> > improved, so I
> > wonder if they are what is causing the error rather than the vector parts? 
> > Also in
> > the kernel log I see the following messages appearing:
> >
> > [3639669.374942] qemu-system-ppc[28591]: segfault (11) at 64b8 nip f87280 
> > lr f8723c
> > code 1 in qemu-system-ppc[94e000+aa0000]
> > [3639669.380015] qemu-system-ppc[28591]: code: 93c10038 91810020 90010044 
> > 7fc802a6
> > 3fde0059 2e030000 3bde6c18 7c9d2378
> > [3639669.385056] qemu-system-ppc[28591]: code: 813e80a0 7cbb2b78 7cda3378 
> > 7cf93b78
> > <81428ff8> 9141001c 39400000 81290000
> >
> > Does that help at all? If not let me know if there are any other tests that 
> > you'd
> > like me to try to help debug this.
>
> One more hint: if I try a build of d8dcbb57e9 along with my 
> tcg_can_emit_vec_op()
> hack and pass --enable-debug-tcg to configure then I get an assert on startup:
>
> qemu-system-ppc: /home/mca/src/qemu/tcg/tcg.c:2207: process_op_defs: 
> Assertion `tdefs
> != ((void *)0)' failed.
> Aborted
>

Mark, Richard, Howard, David,

I just sent v5 of the series, that is (in the sense of net-result of
code changes) equivalent to v4, but the patch 1/7 from v4 is now split
into ten smaller patches. This was done mainly to enable Mark to
perhaps try v5 and bisect, in order to at least somewhat narrow down
the culprit. Most likely it will be patch 5 from v5, that is still
sizeable, but even if this is the case, we can eliminate other smaller
things from consideration.

Sincerely,
Aleksandar

>
> ATB,
>
> Mark.
>