All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Libo Zhou" <zhlb29@foxmail.com>
To: "Philippe Mathieu-Daud" <philmd@redhat.com>,
	"Peter&#38;nbsp;Maydell" <peter.maydell@linaro.org>
Cc: qemu-devel <qemu-devel@nongnu.org>,
	"Aleksandar&#38;nbsp;Markovic" <aleksandar.m.mail@gmail.com>
Subject: Re: illegal hardware instruction during MIPS-I ELF linux useremulation
Date: Thu, 26 Sep 2019 22:31:35 +0800	[thread overview]
Message-ID: <tencent_7AB3CDCC529EAE38265539A9@qq.com> (raw)
In-Reply-To: <c722d11e-e0ff-8a91-d8f3-ee0a31f1df33@redhat.com>

> If you look at the mips_defs[] array in
> target/mips/translate_init.inc.c, the older ISA implemented is MIPS-II:

> $ git grep .insn_flags target/mips/translate_init.inc.c
> translate_init.inc.c:75:        .insn_flags = CPU_MIPS32,
> translate_init.inc.c:97:        .insn_flags = CPU_MIPS32 | ASE_MIPS16,
> translate_init.inc.c:117:        .insn_flags = CPU_MIPS32,
> translate_init.inc.c:137:        .insn_flags = CPU_MIPS32 | ASE_MIPS16,
> translate_init.inc.c:158:        .insn_flags = CPU_MIPS32R2,
> translate_init.inc.c:179:        .insn_flags = CPU_MIPS32R2 | ASE_MIPS16,
> translate_init.inc.c:201:        .insn_flags = CPU_MIPS32R2 | ASE_MIPS16,
> translate_init.inc.c:223:        .insn_flags = CPU_MIPS32R2 | ASE_MIPS16 | ASE_DSP,
> translate_init.inc.c:249:        .insn_flags = CPU_MIPS32R2 | ASE_MIPS16,
> translate_init.inc.c:297:        .insn_flags = CPU_MIPS32R2 | ASE_MIPS16 | ASE_DSP | ASE_MT,
> translate_init.inc.c:323:        .insn_flags = CPU_MIPS32R2 | ASE_MIPS16 | ASE_DSP | ASE_DSP_R2,
> translate_init.inc.c:343:        .insn_flags = CPU_MIPS32R2 | ASE_MICROMIPS,
> translate_init.inc.c:364:        .insn_flags = CPU_MIPS32R2 | ASE_MICROMIPS,
> translate_init.inc.c:410:        .insn_flags = CPU_MIPS32R5 | ASE_MSA,
> translate_init.inc.c:449:        .insn_flags = CPU_MIPS32R6 | ASE_MICROMIPS,
> translate_init.inc.c:488:        .insn_flags = CPU_NANOMIPS32 | ASE_DSP | ASE_DSP_R2 | ASE_DSP_R3 |
> translate_init.inc.c:511:        .insn_flags = CPU_MIPS3,
> translate_init.inc.c:531:        .insn_flags = CPU_VR54XX,
> translate_init.inc.c:552:        .insn_flags = CPU_MIPS64,
> translate_init.inc.c:578:        .insn_flags = CPU_MIPS64,
> translate_init.inc.c:607:        .insn_flags = CPU_MIPS64 | ASE_MIPS3D,
> translate_init.inc.c:636:        .insn_flags = CPU_MIPS64R2 | ASE_MIPS3D,
> translate_init.inc.c:657:        .insn_flags = CPU_MIPS64R2,
> translate_init.inc.c:681:        .insn_flags = CPU_MIPS64R2,
> translate_init.inc.c:721:        .insn_flags = CPU_MIPS64R6 | ASE_MSA,
> translate_init.inc.c:761:        .insn_flags = CPU_MIPS64R6 | ASE_MSA,
> translate_init.inc.c:781:        .insn_flags = CPU_LOONGSON2E,
> translate_init.inc.c:801:        .insn_flags = CPU_LOONGSON2F,
> translate_init.inc.c:830:        .insn_flags = CPU_MIPS64R2 | ASE_DSP | ASE_DSP_R2,

> So currently there is no MIPS-I only CPU.
> Note that the code got written with MIPS32 in mind, and implementing
> MIPS-I requires a considerable amount of change in the codebase.

Hi Philippe,

I just figured out what the problem was. The custom compiler I used just modified the opcode fields of sw and lw instructions of MIPS, so QEMU didn't recognize them out of the box.
I just added the support in decode_opc function in translate.c, and I also added my own CPU model in translate_init.inc.c. However, the illegal instruction exception is still there.

I am suspecting that the way I added my own CPU model in translate_init.inc.c is wrong. Below is what I added:
...
+{
+    .name = "MyCPU",
+    .insn_flags = CPU_MIPS1 | INSN_MYCPU,
+},
...
I just need to simulate it's instruction set in linux user emulation, I didn't include CP0* items in the list. Is this good enough to add a new CPU model?

Thanks,
Libo Zhou

  parent reply	other threads:[~2019-09-26 14:34 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-23  8:15 illegal hardware instruction during MIPS-I ELF linux user emulation Libo Zhou
2019-09-23 12:04 ` Libo Zhou
2019-09-23 12:19   ` illegal " Peter Maydell
2019-09-24  2:10     ` illegal hardware instruction during MIPS-I ELF linux useremulation Libo Zhou
2019-09-24  2:23       ` Libo Zhou
2019-09-23 14:38 ` illegal hardware instruction during MIPS-I ELF linux user emulation Philippe Mathieu-Daudé
2019-09-23 14:42   ` Peter Maydell
2019-09-23 14:50     ` Philippe Mathieu-Daudé
2019-09-26 14:31   ` Libo Zhou [this message]
2019-09-26 15:46     ` illegal hardware instruction during MIPS-I ELF linux useremulation Philippe Mathieu-Daudé
2019-09-27  8:59       ` Libo Zhou
  -- strict thread matches above, loose matches on Subject: below --
2019-09-23 16:25 Libo Zhou
2019-09-23 16:41 ` Peter Maydell
2019-09-24  1:05   ` Libo Zhou
2019-09-24  2:32     ` Libo Zhou
2019-09-24 13:31       ` Libo Zhou
2019-09-24 13:42         ` Philippe Mathieu-Daudé
2019-09-24  9:36     ` Peter Maydell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=tencent_7AB3CDCC529EAE38265539A9@qq.com \
    --to=zhlb29@foxmail.com \
    --cc=aleksandar.m.mail@gmail.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.