[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
Very weird. The emulations now aren't at the same address as before either (0xd4c3 rather than 0xd71b). Is the *only* difference that you added these printf()s -- is it at all possible that the guest is executing down a different path here for other reasons? If it's really down to the printf()s then I guess you'll have to shuffle/remove printf()s to get the old behaviour back. -- Keir On 7/8/07 12:35, "Brady Chen" <chenchp@xxxxxxxxx> wrote: > it's strange: > if i add these prints, i get " Unknown opcode", not "trap". > ===added printf > [root@localhost firmware]# hg diff -p 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 19:33:55 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>", > @@ -128,6 +128,7 @@ address(struct regs *regs, unsigned seg, > unsigned seg_base, seg_limit; > unsigned entry_low, entry_high; > > + printf("f 1\n"); > if (seg == 0) { > if (mode == VM86_REAL || mode == VM86_REAL_TO_PROTECTED) > return off; > @@ -135,12 +136,16 @@ address(struct regs *regs, unsigned seg, > panic("segment is zero, but not in real mode!\n"); > } > > + printf("f 2\n"); > if (mode == VM86_REAL || seg > oldctx.gdtr_limit || > (mode == VM86_REAL_TO_PROTECTED && regs->cs == seg)) > return ((seg & 0xFFFF) << 4) + off; > > + printf("f 3\n"); > gdt_phys_base = guest_linear_to_phys(oldctx.gdtr_base); > + printf("f 4\n"); > if (gdt_phys_base != (uint32_t)gdt_phys_base) { > + printf("f 5\n"); > printf("gdt base address above 4G\n"); > cpuid_addr_value(gdt_phys_base + 8 * (seg >> 3), &entry); > } else > @@ -152,14 +157,17 @@ address(struct regs *regs, unsigned seg, > seg_base = (entry_high & 0xFF000000) | ((entry >> 16) & 0xFFFFFF); > seg_limit = (entry_high & 0xF0000) | (entry_low & 0xFFFF); > > + printf("f 6\n"); > if (entry_high & 0x8000 && > ((entry_high & 0x800000 && off >> 12 <= seg_limit) || > (!(entry_high & 0x800000) && off <= seg_limit))) > return seg_base + off; > + printf("f 7\n"); > > panic("should never reach here in function address():\n\t" > "entry=0x%08x%08x, mode=%d, seg=0x%08x, offset=0x%08x\n", > entry_high, entry_low, mode, seg, off); > + printf("f 8\n"); > > return 0; > } > @@ -286,6 +294,7 @@ fetch8(struct regs *regs) > unsigned addr = address(regs, regs->cs, MASK16(regs->eip)); > > regs->eip++; > + printf("f 9\n"); > return read8(addr); > } > > ===output when add many printf > (XEN) HVM12: 0x0000D4C3: 0xD00:0x04C3 (0) addr32addr32f 1 > (XEN) HVM12: f 2 > (XEN) HVM12: f 9 > (XEN) HVM12: f 1 > (XEN) HVM12: f 2 > (XEN) HVM12: 0x0000D4C3: 0xD00:0x04C3 (0) data32data32f 1 > (XEN) HVM12: f 2 > (XEN) HVM12: f 9 > (XEN) HVM12: f 1 > (XEN) HVM12: f 2 > (XEN) HVM12: 0x0000D4C3: 0xD00:0x04C3 (0) opc 0x83opc 0xD7704f 1 > (XEN) HVM12: f 2 > (XEN) HVM12: Unknown opcode at 0D00:04C3=0xD4C3 > (XEN) HVM12: Halt called from %eip 0xD3B4A > > On 8/7/07, Brady Chen <chenchp@xxxxxxxxx> wrote: >> 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |