[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


  • To: "Keir Fraser" <keir@xxxxxxxxxxxxx>
  • From: "Brady Chen" <chenchp@xxxxxxxxx>
  • Date: Wed, 8 Aug 2007 23:42:45 +0800
  • Cc: tygrawy@xxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, Z24 <z24@xxxxxxx>, AL.LINUX@xxxxxxxxxxx
  • Delivery-date: Wed, 08 Aug 2007 08:40:19 -0700
  • 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=nziPBeyktOEsj5rLAdPyNUNQdtqvwqdMUhUusgViPtG7xeObFWzTnFN4dl0nErxWXDv0lmE3E9F8AyAVKjk9QkzZHBcEf+4mPQZKzLrXp3Cconu0Evb23sVzcCSCCn1kkHtcSeg++ztp4681zydFuj8ksjFidIAyvPXQyVPpWfo=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Hi, Keir, thanks for your patient.
I dumped the registers when eip is D71F, seems it's a large buffer copy.

(XEN) HVM8: eax        7E80 ecx        2D1E edx           0 ebx        4048
(XEN) HVM8: esp       D7B74 ebp        1FF0 esi         7BE edi       C31FE
(XEN) HVM8: trapno        D errno         0
(XEN) HVM8: eip         71F cs          D00 eflags    33206
(XEN) HVM8: uesp       CFB4 uss           0
(XEN) HVM8: ves         D00 vds         D00 vfs           0 vgs           0
(XEN) HVM8: cr0       50032 cr2           0 cr3           0 cr4         651
(XEN) HVM8:
(XEN) HVM8: 0x0000D71F: 0xD00:0x071F (0) data32
(XEN) HVM8: 0x0000D71F: 0xD00:0x071F (0) opc 0x83
(XEN) HVM8: 0x0000D71B: 0xD00:0x071B (0) %es:
(XEN) HVM8: 0x0000D71B: 0xD00:0x071B (0) addr32
(XEN) HVM8: 0x0000D71D: 0xD00:0x071D (0) movw %ax, *0xD03FE
(XEN) HVM8: eax        64FF ecx        2D1D edx           0 ebx        404A
(XEN) HVM8: esp       D7B74 ebp        1FF0 esi         7BE edi       C33FE
(XEN) HVM8: trapno        D errno         0
(XEN) HVM8: eip         71F cs          D00 eflags    33206
(XEN) HVM8: uesp       CFB4 uss           0
(XEN) HVM8: ves         D00 vds         D00 vfs           0 vgs           0
(XEN) HVM8: cr0       50032 cr2           0 cr3           0 cr4         651
(XEN) HVM8:
(XEN) HVM8: 0x0000D71F: 0xD00:0x071F (0) data32
(XEN) HVM8: 0x0000D71F: 0xD00:0x071F (0) opc 0x83
(XEN) HVM8: 0x0000D71B: 0xD00:0x071B (0) %es:
(XEN) HVM8: 0x0000D71B: 0xD00:0x071B (0) addr32
(XEN) HVM8: 0x0000D71D: 0xD00:0x071D (0) movw %ax, *0xD05FE
(XEN) HVM8: eax         A75 ecx        2D1C edx           0 ebx        404C
(XEN) HVM8: esp       D7B74 ebp        1FF0 esi         7BE edi       C35FE
(XEN) HVM8: trapno        D errno         0
(XEN) HVM8: eip         71F cs          D00 eflags    33202
(XEN) HVM8: uesp       CFB4 uss           0
(XEN) HVM8: ves         D00 vds         D00 vfs           0 vgs           0
(XEN) HVM8: cr0       50032 cr2           0 cr3           0 cr4         651
(XEN) HVM8:
(XEN) HVM8: 0x0000D71F: 0xD00:0x071F (0) data32
(XEN) HVM8: 0x0000D71F: 0xD00:0x071F (0) opc 0x83
(XEN) HVM8: 0x0000D71F: 0xD00:0x071F (0) external interrupt 8
(XEN) HVM8: 0x000F9BF7: 0xF000:0x9BF7 (0) opc 0xC3
(XEN) HVM8: 0x0000D71B: 0xD00:0x071B (0) %es:
(XEN) HVM8: 0x0000D71B: 0xD00:0x071B (0) addr32
(XEN) HVM8: 0x0000D71D: 0xD00:0x071D (0) movw %ax, *0xD07FE
(XEN) HVM8: Trap (0x6) while in real mode
(XEN) HVM8: eax         D00 ecx       D7B54 edx         71F ebx       D7B54
(XEN) HVM8: esp       D7A94 ebp       D7AE0 esi       D7A70 edi         D00
(XEN) HVM8: trapno        6 errno         0
(XEN) HVM8: eip       D0800 cs           10 eflags    13046
(XEN) HVM8: uesp      D7B54 uss           2
(XEN) HVM8: ves       D5178 vds       D5246 vfs       D07FE vgs       D7AF4
(XEN) HVM8: cr0       50032 cr2           0 cr3           0 cr4         651
(XEN) HVM8:
(XEN) HVM8: Halt called from %eip 0xD037C


On 8/8/07, Keir Fraser <keir@xxxxxxxxxxxxx> wrote:
> 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®.