[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



Disassembled the interesting bit by hand:

D700: 66 03 DF               add %edi,%ebx
D703: 66 83 C3 02            add $2,%ebx
D707: 66 81 C7 FE 01 00 00   add $0x1fe,%edi
D70E: 66 49                  dec %ecx
D710: 66 0B C9               or  %ecx,%ecx
D713: 0F 84 17 00            jz  0xd72e
D717: 26 67 8B 03            mov %es:(%ebx),%ax
D71B: 26 67 89 07            mov %ax,%es:(%edi)
D71F: 66 83 C3 02            add $2,%ebx
D723: 66 81 C7 00 02 00 00   add $0x200,%edi
D72A: 66 49                  dec %ecx
D72C: EB E2                  jmp 0xd710
D72E: 66 61                  popal
D730: 90                     nop
D731: 1F                     pop %ds
D732: 07                     pop %es
D733: C3                     ret

It's a fairly odd copy loop! It'd be nice to get a register dump when
emulating this so that we can see e.g., what memory range is supposed to be
affected.

 -- Keir


On 8/8/07 13:12, "Brady Chen" <chenchp@xxxxxxxxx> wrote:

> Hi Keir,
> here the memory dump from D680 ~ D780, how to analyze it? any tools? thanks
> 
> (XEN) HVM17: 0x0000D680: D2 0F 84 0B 00 66 8B FE 1E 07 66 8B C2 E8 71 03
> (XEN) HVM17: 0x0000D690: 66 8B C6 66 5A 66 59 66 42 66 51 66 56 E8 3F 06
> (XEN) HVM17: 0x0000D6A0: 66 85 C0 0F 84 BA FA 66 5E 66 59 66 8B FE 1E 07
> (XEN) HVM17: 0x0000D6B0: E8 4E 03 66 8B C6 66 8B D9 66 59 66 5A 66 51 66
> (XEN) HVM17: 0x0000D6C0: 56 66 D1 E9 E8 F8 FD 66 85 C0 0F 84 93 FA 66 5E
> (XEN) HVM17: 0x0000D6D0: 66 59 66 03 E1 07 66 5F 66 59 66 8B D0 66 58 66
> (XEN) HVM17: 0x0000D6E0: 5B 66 8B DA E9 F5 FE 06 1E 66 60 26 67 66 0F B7
> (XEN) HVM17: 0x0000D6F0: 5F 04 26 67 66 0F B7 4F 06 66 0B C9 0F 84 61 FA
> (XEN) HVM17: 0x0000D700: 66 03 DF 66 83 C3 02 66 81 C7 FE 01 00 00 66 49
> (XEN) HVM17: 0x0000D710: 66 0B C9 0F 84 17 00 26 67 8B 03 26 67 89 07 66
> (XEN) HVM17: 0x0000D720: 83 C3 02 66 81 C7 00 02 00 00 66 49 EB E2 66 61
> (XEN) HVM17: 0x0000D730: 90 1F 07 C3 06 1E 66 60 66 B8 01 00 00 00 66 A3
> (XEN) HVM17: 0x0000D740: 1E 02 66 A1 1A 02 66 03 06 52 02 66 A3 5A 02 66
> (XEN) HVM17: 0x0000D750: 03 06 52 02 66 A3 4A 02 66 A1 30 00 66 0F B6 1E
> (XEN) HVM17: 0x0000D760: 0D 00 66 F7 E3 66 8B 1E 4A 02 66 89 07 66 A3 10
> (XEN) HVM17: 0x0000D770: 00 83 C3 04 66 A1 56 02 66 89 07 A3 0E 00 83 C3
> (XEN) HVM17: 0x0000D780: 04 66 89 1E 4A 02 66 8B 1E 1A 02 1E 07 E8 37 F9
> 
> 
> On 8/8/07, Keir Fraser <keir@xxxxxxxxxxxxx> wrote:
>> Well, some bytes are already screwed at that point, so I'd try to do it
>> earlier (e.g., when you are emulating one of the earlier MOVs, for example).
>> But yes, dumping by printf() is fine. Put address at start of line, and then
>> dump 16 bytes as "%02x ". Should end up with 16 lines of 16 bytes each.
>> 
>>  -- Keir
>> 
>> On 8/8/07 10:38, "Brady Chen" <chenchp@xxxxxxxxx> wrote:
>> 
>>> Thanks,
>>> can you show me a way to dump bytes around 0xd680 ~ 0xd780?
>>> just printf in trap() of vmxassist?
>>> 
>>> On 8/8/07, Keir Fraser <keir@xxxxxxxxxxxxx> wrote:
>>>> You could give that a try, but really it shouldn't be going at
>>>> 0xc0000-0x100000 at all. There are usually ROM images residing there.
>>>> 
>>>> This is more likely to be a mis-emulation. Can you get a dump of the bytes
>>>> around 0xd680-0xd780? Then we could try and work out what the guest is
>>>> trying to execute, and see whether emulation is going wrong. A register
>>>> dump
>>>> from the guest (dump_regs()) at the start of every call to opcode() might
>>>> also be useful.
>>>> 
>>>>  -- Keir
>>>> 
>>>> On 8/8/07 09:25, "Brady Chen" <chenchp@xxxxxxxxx> wrote:
>>>> 
>>>>> Hi Keir,
>>>>> I think the 7th issue I mentioned is the root cause,
>>>>> so I have a question.
>>>>> For real mode simulation, the simulator is running in the same space
>>>>> with the codes to-be-simulated? then how to protect simulator from
>>>>> being modified by to-be-simulated code?
>>>>> 
>>>>> can I change the address of vmxassist to a higher address? just try to
>>>>> give more space to the to-be-simulated windows.
>>>>> 
>>>>> On 8/8/07, Brady Chen <chenchp@xxxxxxxxx> wrote:
>>>>>> it's possible.
>>>>>> any ideas to trace the function stack of xen guest? like "bt" command in
>>>>>> gdb.
>>>>>> 
>>>>>> I did some analysis:
>>>>>> 1. the call flow is opcode()->fetch8()->address()
>>>>>> 2. only the printf in address() will change the behaver of crash.
>>>>>> 3. and the crash EIP (0xD0800) is in the address() from the objdump.
>>>>>> 4. the address() will be invoked more then 40, 000 times in one
>>>>>> simulation, before the crash.
>>>>>> 5. seems there are no recursive invoking in opcode(), fetch8(), address()
>>>>>> 6. from the output of "xen dmesg", before the crash, a instructions
>>>>>> sequence is simulated several times (you could check the  previous
>>>>>> mails i send for "xen dmesg" output)
>>>>>> 7. before the trap, the simulated instruction is "movw %ax, *0xD07FE",
>>>>>> and the "*0xD07FE" is just the address of address(), (you could get
>>>>>> the objdump output from previous mails too), so i think it's the
>>>>>> simulation which crash the memory of address().
>>>>>> 
>>>>>> On 8/8/07, Keir Fraser <keir@xxxxxxxxxxxxx> wrote:
>>>>>>> Stack corruption/overflow, possibly?
>>>>>>> 
>>>>>>>  K.
>>>>>>> 
>>>>>>> On 7/8/07 17:06, "Brady Chen" <chenchp@xxxxxxxxx> wrote:
>>>>>>> 
>>>>>>>> Yes, the printfs are the only changes. once I remove these prints, the
>>>>>>>> trap comes back, with the same EIP (D0800)
>>>>>>>> 
>>>>>>>> I tried to keep the first two printfs, the trap comes with different
>>>>>>>> EIP(D19FD)
>>>>>>>> static unsigned
>>>>>>>> address(struct regs *regs, unsigned seg, unsigned off)
>>>>>>>> {
>>>>>>>>         uint64_t gdt_phys_base;
>>>>>>>>         unsigned long long entry;
>>>>>>>>         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;
>>>>>>>>                 else
>>>>>>>>                         panic("segment is zero, but not in real
>>>>>>>> mode!\n");
>>>>>>>>         }
>>>>>>>> 
>>>>>>>>         printf("f 2\n");
>>>>>>>> 
>>>>>>>> xen dmesg output:
>>>>>>>> (XEN) HVM3: 0x0000D71F: 0xD00:0x071F (0) opc 0x83
>>>>>>>> (XEN) HVM3: f 1
>>>>>>>> (XEN) HVM3: f 2
>>>>>>>> (XEN) HVM3: 0x0000D71F: 0xD00:0x071F (0) external interrupt 8
>>>>>>>> (XEN) HVM3: f 1
>>>>>>>> (XEN) HVM3: f 1
>>>>>>>> (XEN) HVM3: f 1
>>>>>>>> (XEN) HVM3: Trap (0x6) while in real mode
>>>>>>>> (XEN) HVM3: eax        CFAE ecx           0 edx           0 ebx
>>>>>>>> D75B4
>>>>>>>> (XEN) HVM3: esp       D7564 ebp       D75A0 esi         71F edi
>>>>>>>> 8
>>>>>>>> (XEN) HVM3: trapno        6 errno         0
>>>>>>>> (XEN) HVM3: eip       D19FD cs           10 eflags    13046
>>>>>>>> (XEN) HVM3: uesp       CFAE uss           0
>>>>>>>> (XEN) HVM3: ves       D4C44 vds           8 vfs          83 vgs
>>>>>>>> 71F
>>>>>>>> (XEN) HVM3: cr0       50032 cr2           0 cr3           0 cr4
>>>>>>>> 651
>>>>>>>> (XEN) HVM3:
>>>>>>>> (XEN) HVM3: Halt called from %eip 0xD037C
>>>>>>>> 
>>>>>>>> 
>>>>>>>> and the objdump shows that:
>>>>>>>> 000d1970 <interrupt>:
>>>>>>>>    d1970:       55                      push   %ebp
>>>>>>>>    d1971:       89 e5                   mov    %esp,%ebp
>>>>>>>>    d1973:       57                      push   %edi
>>>>>>>>    d1974:       89 d7                   mov    %edx,%edi
>>>>>>>>    d1976:       56                      push   %esi
>>>>>>>>   ....
>>>>>>>>    d19f8:       66 89 30                mov    %si,(%eax)
>>>>>>>>    d19fb:       31 d2                   xor    %edx,%edx
>>>>>>>>    d19fd:       8d 34 bd 00 00 00 00    lea    0x0(,%edi,4),%esi
>>>>>>>>    d1a04:       81 63 30 ff fd ff ff    andl   $0xfffffdff,0x30(%ebx)
>>>>>>>>    d1a0b:       89 d8                   mov    %ebx,%eax
>>>>>>>>    d1a0d:       89 34 24                mov    %esi,(%esp)
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 8/7/07, Keir Fraser <keir@xxxxxxxxxxxxx> wrote:
>>>>>>>>> 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
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> 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


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.