Patchwork [2/3] target-i386/translate.c: mov to/from crN/drN: ignore mod bits

login
register
mail settings
Submitter Matthew Ogilvie
Date July 27, 2012, 6:55 p.m.
Message ID <1343415357-5637-3-git-send-email-mmogilvi_qemu@miniinfo.net>
Download mbox | patch
Permalink /patch/173785/
State New
Headers show

Comments

Matthew Ogilvie - July 27, 2012, 6:55 p.m.
Microport UNIX System V/386 v 2.1 (ca 1987) uses mod R/M bytes for
the control register mov instructions where the mod bits are 0,
even though the 80386 spec claims they are "always" 1's.  The fact
that it ran at all clearly indicates the real chips (at least 386
and 486) just ignores the bits and assumes they are 1's, rather
than trigger an illegal instruction if they aren't.

Also fixed: The dissassembled kernel also accesses debug
registers in a similar way, although other problems prevent
me verifiing that those instructions are reachable in UNIX.

Signed-off-by: Matthew Ogilvie <mmogilvi_qemu@miniinfo.net>
---

Alternatives?:

Potentially someone might want to make this dependent on some kind
of configuration option (what specific CPU it is emulating, or some
kind of quirks flag).

Or somehow log if it encounters unspecified instructions
like this, as a kind of warning mechanism for someone debugging
an OS.  (Although I'm not sure exactly what the qemu way to
log such a thing would be.)

But my initial thought is that neither of these are worth the effort.

------
Matthew Ogilvie   [mmogilvi_qemu@miniinfo.net]
------

 target-i386/translate.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)
malc - July 27, 2012, 8:53 p.m.
On Fri, 27 Jul 2012, Matthew Ogilvie wrote:

> Microport UNIX System V/386 v 2.1 (ca 1987) uses mod R/M bytes for
> the control register mov instructions where the mod bits are 0,
> even though the 80386 spec claims they are "always" 1's.  The fact
> that it ran at all clearly indicates the real chips (at least 386
> and 486) just ignores the bits and assumes they are 1's, rather
> than trigger an illegal instruction if they aren't.
> 

AMD's document is explicit about it:

This instruction is always treated as a register-to-register (MOD = 11)
instruction, regardless of the encoding of the MOD field in the MODR/M
byte.

24594.pdf page 316

So i belive this patch should just be applied, thanks.

[..snip..]

Patch

diff --git a/target-i386/translate.c b/target-i386/translate.c
index 1988dae..d056842 100644
--- a/target-i386/translate.c
+++ b/target-i386/translate.c
@@ -7465,8 +7465,12 @@  static target_ulong disas_insn(DisasContext *s, target_ulong pc_start)
             gen_exception(s, EXCP0D_GPF, pc_start - s->cs_base);
         } else {
             modrm = ldub_code(s->pc++);
-            if ((modrm & 0xc0) != 0xc0)
-                goto illegal_op;
+            /* Ignore the mod bits (assume (modrm&0xc0)==0xc0).
+             * The 80386 reference manual says the bits are
+             * always 1, and doesn't say what happens if they aren't.
+             * But testing shows that the bits are just assumed to be
+             * 1s.
+             */
             rm = (modrm & 7) | REX_B(s);
             reg = ((modrm >> 3) & 7) | rex_r;
             if (CODE64(s))
@@ -7507,8 +7511,12 @@  static target_ulong disas_insn(DisasContext *s, target_ulong pc_start)
             gen_exception(s, EXCP0D_GPF, pc_start - s->cs_base);
         } else {
             modrm = ldub_code(s->pc++);
-            if ((modrm & 0xc0) != 0xc0)
-                goto illegal_op;
+            /* Ignore the mod bits (assume (modrm&0xc0)==0xc0).
+             * The 80386 reference manual says the bits are
+             * always 1, and doesn't say what happens if they aren't.
+             * But testing shows that the bits are just assumed to be
+             * 1s.
+             */
             rm = (modrm & 7) | REX_B(s);
             reg = ((modrm >> 3) & 7) | rex_r;
             if (CODE64(s))