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
|
Home