qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
Cc: "QEMU Developers" <qemu-devel@nongnu.org>,
	"Richard Henderson" <rth@twiddle.net>,
	"Thomas Huth" <thuth@redhat.com>,
	"Andreas Färber" <afaerber@suse.de>,
	"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] disas: Disassembler disagrees with translator over instruction decoding
Date: Thu, 29 Jun 2017 19:42:08 +0100	[thread overview]
Message-ID: <CAFEAcA9HLbnZnfBisNLPnKuf364kPtq8=0soFmovYRzRWrOtkA@mail.gmail.com> (raw)
In-Reply-To: <57ad91ad-7cc4-913f-7f45-c5906779bedf@amsat.org>

On 29 June 2017 at 19:20, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> I got this "Disassembler disagrees with translator over instruction
> decoding" message asking to get reported here.
>
> What happens here is coreboot incorrectly emits a Pentium2 instruction while
> I'm running qemu with a Pentium cpu. I didn't know what to expect but got
> this error message, then qemu keep looping using 100% cpu.

So the primary cause of this message is when the disassembler
(ie disas/) says "the insn at this PC is X bytes long", but
the size it got passed by the translator in target/whatever
is not X. Since the size passed to target_disas() is usually
"start PC of insn minus PC of insn after it's been advanced
by the decoder", this works OK for insns correctly understood
and also for insns which are fixed-length (or easily-identified
length like Thumb). But it doesn't work if insns are variable
length and the decoder bails out to "illegal instruction"
early, like the i386 decoder does.

(Specifically in this instance we check for CPUID_CMOV and
bail out before doing the cpu_ldub_code() of the modrm byte.)

I think we should either:
 (1) be a lot more careful in decoders for variable-length
insn sets that we really read all the bytes of an insn before
deciding it's an illegal encoding
 (2) decide that this warning message is more trouble than it's
worth and get rid of it entirely (has it ever genuinely
flagged up a bug for anybody?)
 (3) provide a mechanism for the decoder to say "I didn't
actually decode the whole insn so I have no idea how big it is"

There are probably some annoying corner cases involving
variable length instructions that cross page boundaries
where the 2nd page is not readable and the decoder bails
out early: does real hardware give an insn abort or an
illegal insn exception in that kind of case?

thanks
-- PMM

      reply	other threads:[~2017-06-29 18:42 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-29 18:20 [Qemu-devel] disas: Disassembler disagrees with translator over instruction decoding Philippe Mathieu-Daudé
2017-06-29 18:42 ` Peter Maydell [this message]

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='CAFEAcA9HLbnZnfBisNLPnKuf364kPtq8=0soFmovYRzRWrOtkA@mail.gmail.com' \
    --to=peter.maydell@linaro.org \
    --cc=afaerber@suse.de \
    --cc=f4bug@amsat.org \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=thuth@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).