This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "Keir Fraser" <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
From: "Brady Chen" <chenchp@xxxxxxxxx>
Date: Tue, 7 Aug 2007 18:30:35 +0800
Cc: tygrawy@xxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, Z24 <z24@xxxxxxx>, AL.LINUX@xxxxxxxxxxx
Delivery-date: Tue, 07 Aug 2007 03:28:09 -0700
Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=P4VTy4dJDDfOjItxW8G2VAxvQcOEfh/NMmWqLjwt2ac3wQhkbXqiRsaaZ1XDntB0bPks4AdsdusJm8km6csKSEpxjTV+rOEH507mPRCcqT96FdWIcW4ia47lcIHHvT5Q5rORWpfsx68pxFZVQUdcCHlfbZymdKwPi3uuNW3a1MU=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WI9q7Kheqc3tmQ7XMKSRE1r+a/xz6FkuXjqpQXx42A+avzGCN7uN86mx3IR9qWTWzMcXdB1DQnWnEMEzp0kthmpE0gHz7Imy0h7cd4oZG+ceb404HzUlHx00RhOcJJJmbeS3mwtEuTjFrvspLYe86Ts+1r1XB4nKm+F0LX1wGEE=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C2DDFB6C.13AD8%keir@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C2DDFA11.13AD3%keir@xxxxxxxxxxxxx> <C2DDFB6C.13AD8%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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[] = {
@@ -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());
+               printf("0xd0800 is 0x%0x\n", *((unsigned short*)0xd0800));
+               printf("0xd0804 is 0x%0x\n", *((unsigned short*)0xd0804));

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: 0xd0800 is 0xFFFF
(XEN) HVM6: 0xd0804 is 0x7D8B
(XEN) HVM6: Halt called from %eip 0xD037C

   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

<Prev in Thread] Current Thread [Next in Thread>