[Qemu-devel] Re: SMM jmp weirdness

[Stefan Reinauer]

On Thu, Nov 11, 2010 at 4:53 PM, Stefan Reinauer <address@hidden> wrote:
> Hi,
>
> I'm looking at the following piece of code running under QEMU
>
>   0x38000:     66 bd 90 f8 27 3f       mov    $0x3f27f890,%ebp ;
> target address for jmp
>    0x38006:     66 2e 2b 2e f8 fe       sub    %cs:0xfef8,%ebp    ;
> subtract SMBASE
>    0x3800c:     66 ff e5                     jmpl   *%ebp
>
> The code is run in system management mode and should eventually jump
> to 0x3f27f890. However, that jump fails and QEMU continues code
> execution at 0x3800f. I suspect this is due to some missing SMM
> special case in translate.c:disas_insn() in the jmp Ev path, but I'm
> not sure yet where to go from there.
> Can anyone toss me in the right direction?

The good thing: I was wrong, that jmpl seems to work like intended.
Thanks to Alex Graf for pointing me in the right direction for
debugging.

However, a few instructions later, the code encounters this instruction:

0x3f2af89e:    e8 05 0b 00 00       call   0x3f2a03a6

We're in SMM, but with CS limit set to 4GB. However, stepping into
this instruction we end up at 0x303a6.

Remember, CS is 0x3000.

So applying the following patch gets us beyond this point, but it is a
bit of a hack:

--- a/target-i386/translate.c
+++ b/target-i386/translate.c
@@ -6257,7 +6257,7 @@ static target_ulong disas_insn(DisasContext *s,
target_ulong pc_start)
                 tval = (int16_t)insn_get(s, OT_WORD);
             next_eip = s->pc - s->cs_base;
             tval += next_eip;
-            if (s->dflag == 0)
+            if ((s->dflag == 0) && !(s->flags & HF_SMM_MASK))
                 tval &= 0xffff;
             else if(!CODE64(s))
                 tval &= 0xffffffff;

With this change the code gets to the point of "ret" where a similar
change would be needed.

Generally a lot of &= 0xffff mentioned in the translate.c code seems
to be incorrect, and should rather be &= env->segs[R_CS].limit or
similar.

The same applies for gen_op_andl_T0_ffff(); which should rather be
called gen_op_andl_T0_seg_limit(); and behave accordingly.

Stefan