Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain

["Brady Chen" <chenchp@xxxxxxxxx>]

Hi, Keir,
I made the change as you said:
change diff is:
[root@localhost firmware]# hg diff vmxassist/vm86.c
diff -r 6f18f5bdeea3 tools/firmware/vmxassist/vm86.c
--- a/tools/firmware/vmxassist/vm86.c   Mon Aug 06 15:33:42 2007 +0100
+++ b/tools/firmware/vmxassist/vm86.c   Tue Aug 07 18:26:12 2007 +0800
@@ -40,7 +40,7 @@ static struct regs saved_rm_regs;
 static struct regs saved_rm_regs;

 #ifdef DEBUG
-int traceset = 0;
+int traceset = ~0;

 char *states[] = {
        "<VM86_REAL>",
@@ -620,6 +620,7 @@ movr(struct regs *regs, unsigned prefix,
                        TRACE((regs, regs->eip - eip,
                                "movw %%%s, *0x%x", rnames[r], addr));
                        write16(addr, MASK16(val));
+                       printf("after write16 of movw\n");
                }
                return 1;

@@ -1305,6 +1306,7 @@ opcode(struct regs *regs)
        unsigned eip = regs->eip;
        unsigned opc, modrm, disp;
        unsigned prefix = 0;
+       printf("top of opcode\n");

        if (mode == VM86_PROTECTED_TO_REAL &&
                oldctx.cs_arbytes.fields.default_ops_size) {
@@ -1712,6 +1714,8 @@ trap(int trapno, int errno, struct regs
                if (trapno == 14)
                        printf("Page fault address 0x%x\n", get_cr2());
                dump_regs(regs);
+               printf("0xd0800 is 0x%0x\n", *((unsigned short*)0xd0800));
+               printf("0xd0804 is 0x%0x\n", *((unsigned short*)0xd0804));
                halt();
        }
 }


here is the output:
(XEN) HVM6: top of opcode
(XEN) HVM6: 0x0000D71F: 0xD00:0x071F (0) data32
(XEN) HVM6: 0x0000D71F: 0xD00:0x071F (0) opc 0x83
(XEN) HVM6: top of opcode
(XEN) HVM6: 0x0000D71B: 0xD00:0x071B (0) %es:
(XEN) HVM6: 0x0000D71B: 0xD00:0x071B (0) addr32
(XEN) HVM6: 0x0000D71D: 0xD00:0x071D (0) movw %ax, *0xD07FE
(XEN) HVM6: after write16 of movw
(XEN) HVM6: top of opcode
(XEN) HVM6: Trap (0x6) while in real mode
(XEN) HVM6: eax         D00 ecx           0 edx         71F ebx         71E
(XEN) HVM6: esp       D7554 ebp       D75A0 esi       D7590 edi         D00
(XEN) HVM6: trapno        6 errno         0
(XEN) HVM6: eip       D0800 cs           10 eflags    13046
(XEN) HVM6: uesp      D4C29 uss           2
(XEN) HVM6: ves       D4C18 vds       D4D9C vfs       D07FE vgs       D75B4
(XEN) HVM6: cr0       50032 cr2           0 cr3           0 cr4         651
(XEN) HVM6:
(XEN) HVM6: 0xd0800 is 0xFFFF
(XEN) HVM6: 0xd0804 is 0x7D8B
(XEN) HVM6: Halt called from %eip 0xD037C

objdump:
   d07ef:       e9 2f ff ff ff          jmp    d0723 <address+0x23>
   d07f4:       8b 55 08                mov    0x8(%ebp),%edx
   d07f7:       89 f8                   mov    %edi,%eax
   d07f9:       8b 5d f4                mov    0xfffffff4(%ebp),%ebx
   d07fc:       8b 75 f8                mov    0xfffffff8(%ebp),%esi
   d07ff:       25 ff ff 00 00          and    $0xffff,%eax
   d0804:       8b 7d fc                mov    0xfffffffc(%ebp),%edi
   d0807:       89 ec                   mov    %ebp,%esp
   d0809:       c1 e0 04                shl    $0x4,%eax
   d080c:       01 d0                   add    %edx,%eax
   d080e:       5d                      pop    %ebp

seems the memory is correct, it's crashed in opcode()
and i think it's fetch8(regs) which crash the system. I tried
fetch8(regs) in trap(), but it cause more traps, and let the hvm guest
be reset.

On 8/7/07, Keir Fraser <keir@xxxxxxxxxxxxx> wrote:
> On 7/8/07 10:29, "Keir Fraser" <keir@xxxxxxxxxxxxx> wrote:
>
> > What would be useful is to try to add tracing to see how far vmxassist gets
> > after its last line of tracing before the trap occurs. That last line is
> > currently from vm86.c, line 620. You might try adding extra printf()
> > statements imemdiately after the write16() on line 622, and also at the top
> > of the opcode() function. We need to find out at what point vmxassist is
> > jumping to this bogus address d0800.
>
> Oh, another possibility is that vmxassist has been corrupted in memory. This
> is particularly likely because, according to the objdump, the 'instruction'
> that starts at d0800 is actually valid (it'd be an ADD of some sort).
>
> So, within trap() you might want to read say 16 bytes starting at 0xd0800
> and printf() them. So we can see if they match what objdump says should be
> there.
>
>  -- Keir
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel