[Lguest] lguest: mapping switcher would thwack fixmap

[Paul Bolle]

On Wed, 2013-04-17 at 15:01 +0200, Paul Bolle wrote:
> On Wed, 2013-04-17 at 12:15 +0200, Paul Bolle wrote:
> But the machine once again reboots (triple faults?).

0) I've looked at this using qemu (running a minimal VM running the same
(patched) kernel). That VM also reboots after launching the lguest tool.

1) In that VM's kernel the fixmap is found at 0xffd35000 and the
(patched) switcher is loaded af 0xffd31000. That's to be expected: one
page for the switcher code, two pages for one CPU and one, mysterious,
VMA guard page makes 0x4000.

2) qemu's debug log learns:

Triple fault
CPU Reset (CPU 0)
EAX=ffd32000 EBX=1c139000 ECX=00000001 EDX=dfbec000
ESI=ffd32000 EDI=bfb182cc EBP=dd903f2c ESP=ffd32fb8
EIP=ffd3103d EFL=00000082 [--S----] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =007b 00000000 ffffffff 00cff300 DPL=3 DS   [-WA]
CS =0050 00000000 ffffffff 00cf9b00 DPL=0 CS32 [-RA]
SS =0058 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
DS =007b 00000000 ffffffff 00cff300 DPL=3 DS   [-WA]
FS =00d8 1ef3c000 ffffffff 008f9300 DPL=0 DS16 [-WA]
GS =00e0 dfbf3500 00000018 00409100 DPL=0 DS   [--A]
LDT=0000 00000000 00000000 00008200 DPL=0 LDT
TR =0080 ffd33020 00000067 00008900 DPL=0 TSS32-avl
GDT=     ffd33888 000000ff
IDT=     ffd33088 000007ff
CR0=8005003b CR2=ffd330c8 CR3=1c139000 CR4=00000610
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 
DR6=00000000 DR7=00000000
CCS=00000fb8 CCD=00000089 CCO=LOGICB  
EFER=0000000000000000
FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=00000000000000000000000000000000 XMM01=0000ff00000000000000000000ff0000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000

3) The internet learned me that at triple fault cr2 holds the faulting
address (ie, 0xffd330c8). In this case that is the double fault entry in
the IDT. See, lguest puts the IDT at 0xffd33088, and 0xffd330c8 is 64 or
8 entries bytes above that, and double fault is entry number nine of the
IDT. (This all matches neatly with what lguest is doing with the two
pages it puts in the switcher area per cpu. I'll omit the details. I did
triple check this.)

4) The faulting instruction is at 0xffd3103d. That is in the actual
switcher code, only 61 bytes deep! Peeking into
drivers/lguest/x86/switcher_32.o that is just _after_ this instruction:
        // Once our page table's switched, the Guest is live!
        // The Host fades as we run this final step.
        // Our "struct lguest_pages" is now read-only.
        movl    %ebx, %cr3

That matches what we find in EBX and CR3 above: both contain 0x1c139000.
That value could be legit, as the VM was running with 512M of memory.

5) Any ideas what this all exactly means? Is something going awry when
we put the page tables at (physical) 0x1c139000 or is that perhaps a
bogus value? How can I dig deeper into the cause of this triple fault?


Paul Bolle