|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
Hi, yes, it's crashed in fetch8. it's very slow after I add this print info.
the main function of fetch8 seems to be address(). seems crashed in address().
(XEN) HVM7: after write16 of movw
(XEN) HVM7: top of opcode
(XEN) HVM7: Before fetch8
(XEN) HVM7: eax 7E80 ecx 2D1B edx 0 ebx 404E
(XEN) HVM7: esp D76F4 ebp 1FF0 esi 7BE edi C37FE
(XEN) HVM7: trapno D errno 0
(XEN) HVM7: eip 71F cs D00 eflags 33206
(XEN) HVM7: uesp CFB4 uss 0
(XEN) HVM7: ves D00 vds D00 vfs 0 vgs 0
(XEN) HVM7: cr0 50032 cr2 0 cr3 0 cr4 651
(XEN) HVM7:
(XEN) HVM7: Trap (0x6) while in real mode
(XEN) HVM7: eax D00 ecx 0 edx 71F ebx 89
(XEN) HVM7: esp D75E4 ebp D7630 esi D7620 edi D00
(XEN) HVM7: trapno 6 errno 0
(XEN) HVM7: eip D0800 cs 10 eflags 13046
(XEN) HVM7: uesp 71F uss D76D4
(XEN) HVM7: ves D7610 vds D3AB9 vfs D762C vgs D7644
(XEN) HVM7: cr0 50032 cr2 0 cr3 0 cr4 651
(XEN) HVM7:
(XEN) HVM7: 0xd0800 is 0xFFFF
(XEN) HVM7: 0xd0804 is 0x7D8B
(XEN) HVM7: Halt called from %eip 0xD037C
On 8/7/07, Keir Fraser <keir@xxxxxxxxxxxxx> wrote:
> How about trying:
> printf("Before fetch8\n");
> dump_regs(regs);
> opc = fetch8(regs);
> printf("After fetch8\n");
> switch (opc) { ...
>
> This will let you see what eip is being fetched from, and also confirm that
> the crash happens within fetch8().
>
> You could also try adding more printf()s inside fetch8() and address() to
> find out which specific bit of fetch8() is crashing (if that indeed the
> function that is crashing).
>
> -- Keir
>
> On 7/8/07 11:30, "Brady Chen" <chenchp@xxxxxxxxx> wrote:
>
> > 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
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |