Rebooting from loader causes a "fault" in VMware Workstation

[John Baldwin]

On Tuesday, April 23, 2013 12:09:28 pm Andriy Gapon wrote:
> on 23/04/2013 17:36 Dimitry Andric said the following:
> > I have tried to ascertain it actually arrives at this code when
> > rebooting from the loader, but it does not seem to ever make it there,
> > at least not to the jump to f000:fff0.  Maybe VMware intercepts the
> > switching back to real mode in the previous part, and dies on that, I am
> > not sure.  It is of course rather tricky to print off any debug messages
> > at that point. :-)
> 
> For the inquisitive minds here how last instructions (and CPU state) look
> according to qemu log:
> 
> IN:
> 0x000000000000a030:  xor    %eax,%eax
> 0x000000000000a032:  int    $0x30
> 
> ----------------
> IN:
> 0x00000000000093e0:  cmp    $0x1,%eax
> 0x00000000000093e3:  jne    0x93ff
> 
> ----------------
> IN:
> 0x00000000000093ff:  orb    $0x1,%ss:0x9007
> 0x0000000000009407:  jmp    0x90d2
> 
> ----------------
> IN:
> 0x00000000000090d2:  cli
> 0x00000000000090d3:  mov    $0x1800,%esp
> 0x00000000000090d8:  mov    %cr0,%eax
> 0x00000000000090db:  and    $0x7fffffff,%eax
> 0x00000000000090e0:  mov    %eax,%cr0
> 
> ----------------
> IN:
> 0x00000000000090e3:  xor    %ecx,%ecx
> 0x00000000000090e5:  mov    %ecx,%cr3
> 
> ----------------
> IN:
> 0x00000000000090e8:  lgdtl  0x95d0
> 0x00000000000090ef:  ljmpw  $0x18,$0x90f5
> 
> Triple fault
> CPU Reset (CPU 0)
> ESI=0004503c EDI=3fe50968 EBP=00094a80 ESP=00001800
> EIP=000090ef EFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
> ES =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
> CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
> SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
> DS =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
> FS =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
> GS =0033 0000a000 ffffffff 00cff300 DPL=3 DS   [-WA]
> LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
> TR =0038 00005f98 00002067 00008900 DPL=0 TSS32-avl
> GDT=     ff85c789 00000000

This seems wrong (address is way too high).  I wonder if the gdtdesc was 
trashed by something?  Can you dump memory before the lgdtl instruction at the 
0x95d0 address?

-- 
John Baldwin