Hi all don''t get such envionment to try now. so ask for help here. imagine that two os installed. Xen3.1 + Linux is installed in /dev/hda and windows xp is installed in /dev/hdb I don''t want to reboot to use windows. Is it possiable to boot the hdb windows in xen? i saw there are some threads about P2V in this mail list. will the P2V tools help? thanks _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Artur Linhart - Linux communication
2007-Aug-02 06:50 UTC
RE: [Xen-users] boot a existing windows in hvm domain
Hello, I think in Your case - if windows is installed on a different hdd like windows could is possible, just by the specification of the new HW profile in Your windows version and specification of /dev/hdb as a virtual disk for windows - possibly if in Windows it recognized the disk as D, then could help to put some "dummy" disk as C into the DomU configuration file... I think the main problem will be get windows working with new emulated hardware - maybe You should boot "natively" into the new Xen-Hw-Profile, then deactivate all possible devices in this profile only, then boot the windows as DomU with the Xen-Hw-Profile in safe mode and let recognize the devices (emulated by xen) again in Your new HW-Profile... I could imagine this way is possible... Bu I did not tried it - unfortunatelly I have on my notebook only 1 physical hdd with 1 windows and + linux partition and this makes it impossible to use the whole disk as a source for the virtualization of DomU. Let me know, if this way described by me works, I am very interested in this question... With best regards, Archie P.S. By the way - You know it probably, but - I think You should be sure the /dev/hdb is not mounted in Dom0 at the time You will start DomU. -----Original Message----- From: xen-users-bounces@lists.xensource.com [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of Brady Chen Sent: Monday, July 30, 2007 2:37 PM To: xen-users@lists.xensource.com Subject: [Xen-users] boot a existing windows in hvm domain Hi all don''t get such envionment to try now. so ask for help here. imagine that two os installed. Xen3.1 + Linux is installed in /dev/hda and windows xp is installed in /dev/hdb I don''t want to reboot to use windows. Is it possiable to boot the hdb windows in xen? i saw there are some threads about P2V in this mail list. will the P2V tools help? thanks _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users __________ Informace od NOD32 2429 (20070730) __________ Tato zprava byla proverena antivirovym systemem NOD32. http://www.nod32.cz _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Mon, 30 Jul 2007 20:37:26 +0800, you wrote:>Hi all >don''t get such envionment to try now. so ask for help here. >imagine that two os installed. >Xen3.1 + Linux is installed in /dev/hda >and windows xp is installed in /dev/hdb > >I don''t want to reboot to use windows. Is it possiable to boot the hdb >windows in xen?Yes, it''s possible. I have the same configuration, except I have Xen on /dev/sda and Win on /dev/hda, and I use Xen 3.0.4. I use this configuration: disk = [ ''phy:/dev/sda,ioemu:hda,w'', ''phy:/dev/hda,ioemu:hdb,w'' ] together with the grub mapping options (which you need anyway to boot Windows normally if it isn''t on /dev/hda); when I boot Windows as domU I must be careful to select the "Windows XP" choice on grub menu, otherwise I could destroy both Xen and Windows. See my old post here: http://lists.xensource.com/archives/html/xen-users/2007-02/msg00822.html I suppose there are better and less risky solutions, but I didn''t get deeper since I use it occasionally, and this solution suffices for my needs. Bye -- Z24 http://www.mycomputingart.com/ _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
thank you all, looks like it''s possible. it''s great! Z24, do you get the hardware issue Archie said, that''s my concern too. you know, windows may be bluescreen if the hardware changes. and for your case, i think you could install another grub in the windows disk Archie, I will let you know if it works after I have a try. hopefully next week. -Brady On 8/2/07, Z24 <z24@gmx.net> wrote:> On Mon, 30 Jul 2007 20:37:26 +0800, you wrote: > > >Hi all > >don''t get such envionment to try now. so ask for help here. > >imagine that two os installed. > >Xen3.1 + Linux is installed in /dev/hda > >and windows xp is installed in /dev/hdb > > > >I don''t want to reboot to use windows. Is it possiable to boot the hdb > >windows in xen? > > Yes, it''s possible. I have the same configuration, except I have Xen > on /dev/sda and Win on /dev/hda, and I use Xen 3.0.4. > > I use this configuration: > > disk = [ ''phy:/dev/sda,ioemu:hda,w'', ''phy:/dev/hda,ioemu:hdb,w'' ] > > together with the grub mapping options (which you need anyway to boot > Windows normally if it isn''t on /dev/hda); when I boot Windows as domU > I must be careful to select the "Windows XP" choice on grub menu, > otherwise I could destroy both Xen and Windows. > See my old post here: > http://lists.xensource.com/archives/html/xen-users/2007-02/msg00822.html > > I suppose there are better and less risky solutions, but I didn''t get > deeper since I use it occasionally, and this solution suffices for my > needs. > > Bye > -- > Z24 > http://www.mycomputingart.com/ >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Thu, 2 Aug 2007 17:47:59 +0800, you wrote:>thank you all, >looks like it''s possible. it''s great! > >Z24, >do you get the hardware issue Archie said, that''s my concern too. >you know, windows may be bluescreen if the hardware changes.Before booting the Windows domU I copied the current Windows HW Profile to a new HW Profile, then when I boot the domU I choose the new HW profile. The first time I booted the domU, Windows took some minutes more than usual to load, I suppose it was setting automatically the hardware drivers; the next time it booted only a little slower than when I boot it natively (due to virtualization).>and for your case, i think you could install another grub in the windows diskWhat do you mean? Xen VM configuration with ''phy:/dev/hda,ioemu:hda,w'' only (hda is Windows disk) and grub-install on /dev/hda without mapping? -- Z24 http://www.mycomputingart.com/ _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 8/2/07, Z24 <z24@gmx.net> wrote:> On Thu, 2 Aug 2007 17:47:59 +0800, you wrote: > > >thank you all, > >looks like it''s possible. it''s great! > > > >Z24, > >do you get the hardware issue Archie said, that''s my concern too. > >you know, windows may be bluescreen if the hardware changes. > > Before booting the Windows domU I copied the current Windows HW > Profile to a new HW Profile, then when I boot the domU I choose the > new HW profile. > The first time I booted the domU, Windows took some minutes more than > usual to load, I suppose it was setting automatically the hardware > drivers; the next time it booted only a little slower than when I boot > it natively (due to virtualization). >thanks, I will have a try.> >and for your case, i think you could install another grub in the windows disk > > What do you mean? > Xen VM configuration with ''phy:/dev/hda,ioemu:hda,w'' only (hda is > Windows disk) and grub-install on /dev/hda without mapping?yup, install grub on /dev/hda, it will not be used when you not using xen (i mean when you reboot your PC, and choose windows from the grub menu). but when you use xen to boot /dev/hda, the grub on /dev/hda could be used to load the windows. Don''t know if it really works, don''t have a try now.> > -- > Z24 > http://www.mycomputingart.com/ >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
>> >and for your case, i think you could install another grub in the windows disk >> >> What do you mean? >> Xen VM configuration with ''phy:/dev/hda,ioemu:hda,w'' only (hda is >> Windows disk) and grub-install on /dev/hda without mapping? >yup, install grub on /dev/hda, it will not be used when you not using >xen (i mean when you reboot your PC, and choose windows from the grub >menu). but when you use xen to boot /dev/hda, the grub on /dev/hda >could be used to load the windows. Don''t know if it really works, >don''t have a try now.I think I''ve already tried that without success, but I''m not 100% sure, I''ll give it a try. Thanks. -- Z24 http://www.mycomputingart.com/ _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Artur Linhart - Linux communication
2007-Aug-03 06:49 UTC
RE: [Xen-users] boot a existing windows in hvm domain
Hello, Why is it necessary to have a read-write access from windows onto disk with linux? If this should be only from the reason the windows OS is installed on "disk D:", You can just emulate the "disk C:" by some dummy file... At least You could use the linux disk onto DomU as read-only... If some file transfers are needed, this can be done via some network services like samba or ftp between Dom0 and DomU... With regards, Archie -----Original Message----- From: xen-users-bounces@lists.xensource.com [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of Z24 Sent: Thursday, August 02, 2007 10:26 AM To: xen-users@lists.xensource.com Cc: Brady Chen Subject: Re: [Xen-users] boot a existing windows in hvm domain On Mon, 30 Jul 2007 20:37:26 +0800, you wrote:>Hi all >don''t get such envionment to try now. so ask for help here. >imagine that two os installed. >Xen3.1 + Linux is installed in /dev/hda >and windows xp is installed in /dev/hdb > >I don''t want to reboot to use windows. Is it possiable to boot the hdb >windows in xen?Yes, it''s possible. I have the same configuration, except I have Xen on /dev/sda and Win on /dev/hda, and I use Xen 3.0.4. I use this configuration: disk = [ ''phy:/dev/sda,ioemu:hda,w'', ''phy:/dev/hda,ioemu:hdb,w'' ] together with the grub mapping options (which you need anyway to boot Windows normally if it isn''t on /dev/hda); when I boot Windows as domU I must be careful to select the "Windows XP" choice on grub menu, otherwise I could destroy both Xen and Windows. See my old post here: http://lists.xensource.com/archives/html/xen-users/2007-02/msg00822.html I suppose there are better and less risky solutions, but I didn''t get deeper since I use it occasionally, and this solution suffices for my needs. Bye -- Z24 http://www.mycomputingart.com/ _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users __________ Informace od NOD32 2431 (20070801) __________ Tato zprava byla proverena antivirovym systemem NOD32. http://www.nod32.cz _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Z24, AL, ccing tygrawy@gazeta,pl, for I found he got the same issue. I tried in ThinkPad T60, /dev/sda1 -- windows /dev/sda2 -- Linux + Xen 3.1.0 in xen guest, the whole sda is mapped to virtual hda. disk = [ ''phy:/dev/sda, hda, w'' ] I could see the grub menu in xen guest, and could boot in to the linux (you know, it''s re-enter into the linux), but when I select windows from grub menu, it will hang after print "chainloader +1" the xen dmesg shows: (XEN) HVM1: Trap (0x6) while in real mode (XEN) HVM1: eax D00 ecx 0 edx 71F ebx 71E (XEN) HVM1: esp D7384 ebp D73D0 esi D7364 edi D00 (XEN) HVM1: trapno 6 errno 0 (XEN) HVM1: eip D0800 cs 10 eflags 13046 (XEN) HVM1: uesp D7474 uss 2 (XEN) HVM1: ves D4AB8 vds D4C1D vfs D07FE vgs D7474 (XEN) HVM1: cr0 50032 cr2 0 cr3 0 cr4 651 (XEN) HVM1: (XEN) HVM1: Halt called from %eip 0xD037 tygrawy: I found you have the same issue months ago, have you find out the reason? Thank you very much. http://lists.xensource.com/archives/html/xen-users/2007-07/msg00521.html On 8/2/07, Brady Chen <chenchp@gmail.com> wrote:> On 8/2/07, Z24 <z24@gmx.net> wrote: > > On Thu, 2 Aug 2007 17:47:59 +0800, you wrote: > > > > >thank you all, > > >looks like it''s possible. it''s great! > > > > > >Z24, > > >do you get the hardware issue Archie said, that''s my concern too. > > >you know, windows may be bluescreen if the hardware changes. > > > > Before booting the Windows domU I copied the current Windows HW > > Profile to a new HW Profile, then when I boot the domU I choose the > > new HW profile. > > The first time I booted the domU, Windows took some minutes more than > > usual to load, I suppose it was setting automatically the hardware > > drivers; the next time it booted only a little slower than when I boot > > it natively (due to virtualization). > > > thanks, I will have a try. > > > >and for your case, i think you could install another grub in the windows disk > > > > What do you mean? > > Xen VM configuration with ''phy:/dev/hda,ioemu:hda,w'' only (hda is > > Windows disk) and grub-install on /dev/hda without mapping? > yup, install grub on /dev/hda, it will not be used when you not using > xen (i mean when you reboot your PC, and choose windows from the grub > menu). but when you use xen to boot /dev/hda, the grub on /dev/hda > could be used to load the windows. Don''t know if it really works, > don''t have a try now. > > > > -- > > Z24 > > http://www.mycomputingart.com/ > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Brady Chen
2007-Aug-07 05:48 UTC
[Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
cc to xen-devel, Hi all, someone saw this kind of error before? it''s a Trap 6 error when start the windows. Does it mean that some opcodes in real mode are not be simulated? How can I get the instruction which is not be simulated? I tried to fetch8(regs) in function trap of xen-3.1.0-src/tools/firmware/vmxassist/vm86.c, but it cause more traps, and the hvm is reset immediately. thank you in advance On 8/7/07, Brady Chen <chenchp@gmail.com> wrote:> Hi Z24, AL, > ccing tygrawy@gazeta,pl, for I found he got the same issue. > > I tried in ThinkPad T60, > /dev/sda1 -- windows > /dev/sda2 -- Linux + Xen 3.1.0 > > in xen guest, the whole sda is mapped to virtual hda. > disk = [ ''phy:/dev/sda, hda, w'' ] > > I could see the grub menu in xen guest, and could boot in to the linux > (you know, it''s re-enter into the linux), but when I select windows > from grub menu, it will hang after print "chainloader +1" > the xen dmesg shows: > (XEN) HVM1: Trap (0x6) while in real mode > (XEN) HVM1: eax D00 ecx 0 edx 71F ebx 71E > (XEN) HVM1: esp D7384 ebp D73D0 esi D7364 edi D00 > (XEN) HVM1: trapno 6 errno 0 > (XEN) HVM1: eip D0800 cs 10 eflags 13046 > (XEN) HVM1: uesp D7474 uss 2 > (XEN) HVM1: ves D4AB8 vds D4C1D vfs D07FE vgs D7474 > (XEN) HVM1: cr0 50032 cr2 0 cr3 0 cr4 651 > (XEN) HVM1: > (XEN) HVM1: Halt called from %eip 0xD037 > > tygrawy: > I found you have the same issue months ago, have you find out the > reason? Thank you very much. > > http://lists.xensource.com/archives/html/xen-users/2007-07/msg00521.html > > On 8/2/07, Brady Chen <chenchp@gmail.com> wrote: > > On 8/2/07, Z24 <z24@gmx.net> wrote: > > > On Thu, 2 Aug 2007 17:47:59 +0800, you wrote: > > > > > > >thank you all, > > > >looks like it''s possible. it''s great! > > > > > > > >Z24, > > > >do you get the hardware issue Archie said, that''s my concern too. > > > >you know, windows may be bluescreen if the hardware changes. > > > > > > Before booting the Windows domU I copied the current Windows HW > > > Profile to a new HW Profile, then when I boot the domU I choose the > > > new HW profile. > > > The first time I booted the domU, Windows took some minutes more than > > > usual to load, I suppose it was setting automatically the hardware > > > drivers; the next time it booted only a little slower than when I boot > > > it natively (due to virtualization). > > > > > thanks, I will have a try. > > > > > >and for your case, i think you could install another grub in the windows disk > > > > > > What do you mean? > > > Xen VM configuration with ''phy:/dev/hda,ioemu:hda,w'' only (hda is > > > Windows disk) and grub-install on /dev/hda without mapping? > > yup, install grub on /dev/hda, it will not be used when you not using > > xen (i mean when you reboot your PC, and choose windows from the grub > > menu). but when you use xen to boot /dev/hda, the grub on /dev/hda > > could be used to load the windows. Don''t know if it really works, > > don''t have a try now. > > > > > > -- > > > Z24 > > > http://www.mycomputingart.com/ > > > > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Aug-07 05:59 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
Could be something to do with virtual hard disk geometry. Are you running latest xen-unstable? Was your OS installed with latest xen-unstable, or an older version? -- KEir On 7/8/07 06:48, "Brady Chen" <chenchp@gmail.com> wrote:> cc to xen-devel, > > Hi all, > someone saw this kind of error before? > it''s a Trap 6 error when start the windows. Does it mean that some > opcodes in real mode are not be simulated? How can I get the > instruction which is not be simulated? > > I tried to fetch8(regs) in function trap of > xen-3.1.0-src/tools/firmware/vmxassist/vm86.c, but it cause more > traps, and the hvm is reset immediately. > > thank you in advance > > On 8/7/07, Brady Chen <chenchp@gmail.com> wrote: >> Hi Z24, AL, >> ccing tygrawy@gazeta,pl, for I found he got the same issue. >> >> I tried in ThinkPad T60, >> /dev/sda1 -- windows >> /dev/sda2 -- Linux + Xen 3.1.0 >> >> in xen guest, the whole sda is mapped to virtual hda. >> disk = [ ''phy:/dev/sda, hda, w'' ] >> >> I could see the grub menu in xen guest, and could boot in to the linux >> (you know, it''s re-enter into the linux), but when I select windows >> from grub menu, it will hang after print "chainloader +1" >> the xen dmesg shows: >> (XEN) HVM1: Trap (0x6) while in real mode >> (XEN) HVM1: eax D00 ecx 0 edx 71F ebx 71E >> (XEN) HVM1: esp D7384 ebp D73D0 esi D7364 edi D00 >> (XEN) HVM1: trapno 6 errno 0 >> (XEN) HVM1: eip D0800 cs 10 eflags 13046 >> (XEN) HVM1: uesp D7474 uss 2 >> (XEN) HVM1: ves D4AB8 vds D4C1D vfs D07FE vgs D7474 >> (XEN) HVM1: cr0 50032 cr2 0 cr3 0 cr4 651 >> (XEN) HVM1: >> (XEN) HVM1: Halt called from %eip 0xD037 >> >> tygrawy: >> I found you have the same issue months ago, have you find out the >> reason? Thank you very much. >> >> http://lists.xensource.com/archives/html/xen-users/2007-07/msg00521.html >> >> On 8/2/07, Brady Chen <chenchp@gmail.com> wrote: >>> On 8/2/07, Z24 <z24@gmx.net> wrote: >>>> On Thu, 2 Aug 2007 17:47:59 +0800, you wrote: >>>> >>>>> thank you all, >>>>> looks like it''s possible. it''s great! >>>>> >>>>> Z24, >>>>> do you get the hardware issue Archie said, that''s my concern too. >>>>> you know, windows may be bluescreen if the hardware changes. >>>> >>>> Before booting the Windows domU I copied the current Windows HW >>>> Profile to a new HW Profile, then when I boot the domU I choose the >>>> new HW profile. >>>> The first time I booted the domU, Windows took some minutes more than >>>> usual to load, I suppose it was setting automatically the hardware >>>> drivers; the next time it booted only a little slower than when I boot >>>> it natively (due to virtualization). >>>> >>> thanks, I will have a try. >>> >>>>> and for your case, i think you could install another grub in the windows >>>>> disk >>>> >>>> What do you mean? >>>> Xen VM configuration with ''phy:/dev/hda,ioemu:hda,w'' only (hda is >>>> Windows disk) and grub-install on /dev/hda without mapping? >>> yup, install grub on /dev/hda, it will not be used when you not using >>> xen (i mean when you reboot your PC, and choose windows from the grub >>> menu). but when you use xen to boot /dev/hda, the grub on /dev/hda >>> could be used to load the windows. Don''t know if it really works, >>> don''t have a try now. >>>> >>>> -- >>>> Z24 >>>> http://www.mycomputingart.com/ >>>> >>> >> > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Brady Chen
2007-Aug-07 06:06 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
Hi Keir, Thank you for your reply. I''m using official released version 3.1.0. actually I could boot the linux (/dev/sda2) in xen hvm guest. but failed to boot window (/dev/sda1). the windows in sda1 is not installed in xen hvm guest, it''s installed in the native environment. I''m trying to boot the windows as xen guest. you know, it''s wasting of time to reboot and change to windows. On 8/7/07, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote:> Could be something to do with virtual hard disk geometry. Are you running > latest xen-unstable? Was your OS installed with latest xen-unstable, or an > older version? > > -- KEir > > > On 7/8/07 06:48, "Brady Chen" <chenchp@gmail.com> wrote: > > > cc to xen-devel, > > > > Hi all, > > someone saw this kind of error before? > > it''s a Trap 6 error when start the windows. Does it mean that some > > opcodes in real mode are not be simulated? How can I get the > > instruction which is not be simulated? > > > > I tried to fetch8(regs) in function trap of > > xen-3.1.0-src/tools/firmware/vmxassist/vm86.c, but it cause more > > traps, and the hvm is reset immediately. > > > > thank you in advance > > > > On 8/7/07, Brady Chen <chenchp@gmail.com> wrote: > >> Hi Z24, AL, > >> ccing tygrawy@gazeta,pl, for I found he got the same issue. > >> > >> I tried in ThinkPad T60, > >> /dev/sda1 -- windows > >> /dev/sda2 -- Linux + Xen 3.1.0 > >> > >> in xen guest, the whole sda is mapped to virtual hda. > >> disk = [ ''phy:/dev/sda, hda, w'' ] > >> > >> I could see the grub menu in xen guest, and could boot in to the linux > >> (you know, it''s re-enter into the linux), but when I select windows > >> from grub menu, it will hang after print "chainloader +1" > >> the xen dmesg shows: > >> (XEN) HVM1: Trap (0x6) while in real mode > >> (XEN) HVM1: eax D00 ecx 0 edx 71F ebx 71E > >> (XEN) HVM1: esp D7384 ebp D73D0 esi D7364 edi D00 > >> (XEN) HVM1: trapno 6 errno 0 > >> (XEN) HVM1: eip D0800 cs 10 eflags 13046 > >> (XEN) HVM1: uesp D7474 uss 2 > >> (XEN) HVM1: ves D4AB8 vds D4C1D vfs D07FE vgs D7474 > >> (XEN) HVM1: cr0 50032 cr2 0 cr3 0 cr4 651 > >> (XEN) HVM1: > >> (XEN) HVM1: Halt called from %eip 0xD037 > >> > >> tygrawy: > >> I found you have the same issue months ago, have you find out the > >> reason? Thank you very much. > >> > >> http://lists.xensource.com/archives/html/xen-users/2007-07/msg00521.html > >> > >> On 8/2/07, Brady Chen <chenchp@gmail.com> wrote: > >>> On 8/2/07, Z24 <z24@gmx.net> wrote: > >>>> On Thu, 2 Aug 2007 17:47:59 +0800, you wrote: > >>>> > >>>>> thank you all, > >>>>> looks like it''s possible. it''s great! > >>>>> > >>>>> Z24, > >>>>> do you get the hardware issue Archie said, that''s my concern too. > >>>>> you know, windows may be bluescreen if the hardware changes. > >>>> > >>>> Before booting the Windows domU I copied the current Windows HW > >>>> Profile to a new HW Profile, then when I boot the domU I choose the > >>>> new HW profile. > >>>> The first time I booted the domU, Windows took some minutes more than > >>>> usual to load, I suppose it was setting automatically the hardware > >>>> drivers; the next time it booted only a little slower than when I boot > >>>> it natively (due to virtualization). > >>>> > >>> thanks, I will have a try. > >>> > >>>>> and for your case, i think you could install another grub in the windows > >>>>> disk > >>>> > >>>> What do you mean? > >>>> Xen VM configuration with ''phy:/dev/hda,ioemu:hda,w'' only (hda is > >>>> Windows disk) and grub-install on /dev/hda without mapping? > >>> yup, install grub on /dev/hda, it will not be used when you not using > >>> xen (i mean when you reboot your PC, and choose windows from the grub > >>> menu). but when you use xen to boot /dev/hda, the grub on /dev/hda > >>> could be used to load the windows. Don''t know if it really works, > >>> don''t have a try now. > >>>> > >>>> -- > >>>> Z24 > >>>> http://www.mycomputingart.com/ > >>>> > >>> > >> > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Aug-07 06:32 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
Try downloading http://xenbits.xensource.com/staging/xen-unstable.hg, and build inside tools/firmware. Then use tools/firmware/hvmloader/hvmloader as your HVM ''kernel'' (what you specify as the ''kernel'' in your HVM config file). If that doesn''t help, then track down the crashing %cs:%eip inside vmxassist (objdump -d tools/firmware/vmxassist/vmxassist) and we''ll see if that shows up anything interesting. -- Keir On 7/8/07 07:06, "Brady Chen" <chenchp@gmail.com> wrote:> Hi Keir, > > Thank you for your reply. > I''m using official released version 3.1.0. > actually I could boot the linux (/dev/sda2) in xen hvm guest. > but failed to boot window (/dev/sda1). > > the windows in sda1 is not installed in xen hvm guest, it''s installed > in the native environment. I''m trying to boot the windows as xen > guest. you know, it''s wasting of time to reboot and change to windows. > > > On 8/7/07, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote: >> Could be something to do with virtual hard disk geometry. Are you running >> latest xen-unstable? Was your OS installed with latest xen-unstable, or an >> older version? >> >> -- KEir >> >> >> On 7/8/07 06:48, "Brady Chen" <chenchp@gmail.com> wrote: >> >>> cc to xen-devel, >>> >>> Hi all, >>> someone saw this kind of error before? >>> it''s a Trap 6 error when start the windows. Does it mean that some >>> opcodes in real mode are not be simulated? How can I get the >>> instruction which is not be simulated? >>> >>> I tried to fetch8(regs) in function trap of >>> xen-3.1.0-src/tools/firmware/vmxassist/vm86.c, but it cause more >>> traps, and the hvm is reset immediately. >>> >>> thank you in advance >>> >>> On 8/7/07, Brady Chen <chenchp@gmail.com> wrote: >>>> Hi Z24, AL, >>>> ccing tygrawy@gazeta,pl, for I found he got the same issue. >>>> >>>> I tried in ThinkPad T60, >>>> /dev/sda1 -- windows >>>> /dev/sda2 -- Linux + Xen 3.1.0 >>>> >>>> in xen guest, the whole sda is mapped to virtual hda. >>>> disk = [ ''phy:/dev/sda, hda, w'' ] >>>> >>>> I could see the grub menu in xen guest, and could boot in to the linux >>>> (you know, it''s re-enter into the linux), but when I select windows >>>> from grub menu, it will hang after print "chainloader +1" >>>> the xen dmesg shows: >>>> (XEN) HVM1: Trap (0x6) while in real mode >>>> (XEN) HVM1: eax D00 ecx 0 edx 71F ebx 71E >>>> (XEN) HVM1: esp D7384 ebp D73D0 esi D7364 edi D00 >>>> (XEN) HVM1: trapno 6 errno 0 >>>> (XEN) HVM1: eip D0800 cs 10 eflags 13046 >>>> (XEN) HVM1: uesp D7474 uss 2 >>>> (XEN) HVM1: ves D4AB8 vds D4C1D vfs D07FE vgs D7474 >>>> (XEN) HVM1: cr0 50032 cr2 0 cr3 0 cr4 651 >>>> (XEN) HVM1: >>>> (XEN) HVM1: Halt called from %eip 0xD037 >>>> >>>> tygrawy: >>>> I found you have the same issue months ago, have you find out the >>>> reason? Thank you very much. >>>> >>>> http://lists.xensource.com/archives/html/xen-users/2007-07/msg00521.html >>>> >>>> On 8/2/07, Brady Chen <chenchp@gmail.com> wrote: >>>>> On 8/2/07, Z24 <z24@gmx.net> wrote: >>>>>> On Thu, 2 Aug 2007 17:47:59 +0800, you wrote: >>>>>> >>>>>>> thank you all, >>>>>>> looks like it''s possible. it''s great! >>>>>>> >>>>>>> Z24, >>>>>>> do you get the hardware issue Archie said, that''s my concern too. >>>>>>> you know, windows may be bluescreen if the hardware changes. >>>>>> >>>>>> Before booting the Windows domU I copied the current Windows HW >>>>>> Profile to a new HW Profile, then when I boot the domU I choose the >>>>>> new HW profile. >>>>>> The first time I booted the domU, Windows took some minutes more than >>>>>> usual to load, I suppose it was setting automatically the hardware >>>>>> drivers; the next time it booted only a little slower than when I boot >>>>>> it natively (due to virtualization). >>>>>> >>>>> thanks, I will have a try. >>>>> >>>>>>> and for your case, i think you could install another grub in the windows >>>>>>> disk >>>>>> >>>>>> What do you mean? >>>>>> Xen VM configuration with ''phy:/dev/hda,ioemu:hda,w'' only (hda is >>>>>> Windows disk) and grub-install on /dev/hda without mapping? >>>>> yup, install grub on /dev/hda, it will not be used when you not using >>>>> xen (i mean when you reboot your PC, and choose windows from the grub >>>>> menu). but when you use xen to boot /dev/hda, the grub on /dev/hda >>>>> could be used to load the windows. Don''t know if it really works, >>>>> don''t have a try now. >>>>>> >>>>>> -- >>>>>> Z24 >>>>>> http://www.mycomputingart.com/ >>>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xensource.com >>> http://lists.xensource.com/xen-devel >> >> >>_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Brady Chen
2007-Aug-07 07:58 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
Keir, thank you very much. now I''m using the un-stable version to build hvmloader (only hvmloader rebuild, xen and doman0 kernel is not touched), the same problem. (XEN) HVM1: Trap (0x6) while in real mode (XEN) HVM1: eax D00 ecx 0 edx 71F ebx 71E (XEN) HVM1: esp D74D4 ebp D7520 esi 0 edi D00 (XEN) HVM1: trapno 6 errno 0 (XEN) HVM1: eip D0800 cs 10 eflags 13046 (XEN) HVM1: uesp D75B4 uss 2 (XEN) HVM1: ves D4BC8 vds D4D26 vfs D07FE vgs D75B4 (XEN) HVM1: cr0 50032 cr2 0 cr3 0 cr4 651 (XEN) HVM1: (XEN) HVM1: Halt called from %eip 0xD037C here is some snip from objdump, and i attach the whole objdump as the attachment. 000d0360 <common_trap>: d0360: 60 pusha d0361: b8 18 00 00 00 mov $0x18,%eax d0366: 8e d8 mov %eax,%ds d0368: 8e c0 mov %eax,%es d036a: 8e e0 mov %eax,%fs d036c: 8e e8 mov %eax,%gs d036e: 89 e5 mov %esp,%ebp d0370: 55 push %ebp d0371: ff 75 24 pushl 0x24(%ebp) d0374: ff 75 20 pushl 0x20(%ebp) d0377: e8 d4 2a 00 00 call d2e50 <trap> d037c: 83 c4 0c add $0xc,%esp 000d037f <trap_return>: d037f: 61 popa d0380: 83 c4 08 add $0x8,%esp d0383: cf iret d0384: 8d b6 00 00 00 00 lea 0x0(%esi),%esi d038a: 8d bf 00 00 00 00 lea 0x0(%edi),%edi On 8/7/07, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote:> Try downloading http://xenbits.xensource.com/staging/xen-unstable.hg, and > build inside tools/firmware. Then use tools/firmware/hvmloader/hvmloader as > your HVM ''kernel'' (what you specify as the ''kernel'' in your HVM config > file). > > If that doesn''t help, then track down the crashing %cs:%eip inside vmxassist > (objdump -d tools/firmware/vmxassist/vmxassist) and we''ll see if that shows > up anything interesting. > > -- Keir > > On 7/8/07 07:06, "Brady Chen" <chenchp@gmail.com> wrote: > > > Hi Keir, > > > > Thank you for your reply. > > I''m using official released version 3.1.0. > > actually I could boot the linux (/dev/sda2) in xen hvm guest. > > but failed to boot window (/dev/sda1). > > > > the windows in sda1 is not installed in xen hvm guest, it''s installed > > in the native environment. I''m trying to boot the windows as xen > > guest. you know, it''s wasting of time to reboot and change to windows. > > > > > > On 8/7/07, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote: > >> Could be something to do with virtual hard disk geometry. Are you running > >> latest xen-unstable? Was your OS installed with latest xen-unstable, or an > >> older version? > >> > >> -- KEir > >> > >> > >> On 7/8/07 06:48, "Brady Chen" <chenchp@gmail.com> wrote: > >> > >>> cc to xen-devel, > >>> > >>> Hi all, > >>> someone saw this kind of error before? > >>> it''s a Trap 6 error when start the windows. Does it mean that some > >>> opcodes in real mode are not be simulated? How can I get the > >>> instruction which is not be simulated? > >>> > >>> I tried to fetch8(regs) in function trap of > >>> xen-3.1.0-src/tools/firmware/vmxassist/vm86.c, but it cause more > >>> traps, and the hvm is reset immediately. > >>> > >>> thank you in advance > >>> > >>> On 8/7/07, Brady Chen <chenchp@gmail.com> wrote: > >>>> Hi Z24, AL, > >>>> ccing tygrawy@gazeta,pl, for I found he got the same issue. > >>>> > >>>> I tried in ThinkPad T60, > >>>> /dev/sda1 -- windows > >>>> /dev/sda2 -- Linux + Xen 3.1.0 > >>>> > >>>> in xen guest, the whole sda is mapped to virtual hda. > >>>> disk = [ ''phy:/dev/sda, hda, w'' ] > >>>> > >>>> I could see the grub menu in xen guest, and could boot in to the linux > >>>> (you know, it''s re-enter into the linux), but when I select windows > >>>> from grub menu, it will hang after print "chainloader +1" > >>>> the xen dmesg shows: > >>>> (XEN) HVM1: Trap (0x6) while in real mode > >>>> (XEN) HVM1: eax D00 ecx 0 edx 71F ebx 71E > >>>> (XEN) HVM1: esp D7384 ebp D73D0 esi D7364 edi D00 > >>>> (XEN) HVM1: trapno 6 errno 0 > >>>> (XEN) HVM1: eip D0800 cs 10 eflags 13046 > >>>> (XEN) HVM1: uesp D7474 uss 2 > >>>> (XEN) HVM1: ves D4AB8 vds D4C1D vfs D07FE vgs D7474 > >>>> (XEN) HVM1: cr0 50032 cr2 0 cr3 0 cr4 651 > >>>> (XEN) HVM1: > >>>> (XEN) HVM1: Halt called from %eip 0xD037 > >>>> > >>>> tygrawy: > >>>> I found you have the same issue months ago, have you find out the > >>>> reason? Thank you very much. > >>>> > >>>> http://lists.xensource.com/archives/html/xen-users/2007-07/msg00521.html > >>>> > >>>> On 8/2/07, Brady Chen <chenchp@gmail.com> wrote: > >>>>> On 8/2/07, Z24 <z24@gmx.net> wrote: > >>>>>> On Thu, 2 Aug 2007 17:47:59 +0800, you wrote: > >>>>>> > >>>>>>> thank you all, > >>>>>>> looks like it''s possible. it''s great! > >>>>>>> > >>>>>>> Z24, > >>>>>>> do you get the hardware issue Archie said, that''s my concern too. > >>>>>>> you know, windows may be bluescreen if the hardware changes. > >>>>>> > >>>>>> Before booting the Windows domU I copied the current Windows HW > >>>>>> Profile to a new HW Profile, then when I boot the domU I choose the > >>>>>> new HW profile. > >>>>>> The first time I booted the domU, Windows took some minutes more than > >>>>>> usual to load, I suppose it was setting automatically the hardware > >>>>>> drivers; the next time it booted only a little slower than when I boot > >>>>>> it natively (due to virtualization). > >>>>>> > >>>>> thanks, I will have a try. > >>>>> > >>>>>>> and for your case, i think you could install another grub in the windows > >>>>>>> disk > >>>>>> > >>>>>> What do you mean? > >>>>>> Xen VM configuration with ''phy:/dev/hda,ioemu:hda,w'' only (hda is > >>>>>> Windows disk) and grub-install on /dev/hda without mapping? > >>>>> yup, install grub on /dev/hda, it will not be used when you not using > >>>>> xen (i mean when you reboot your PC, and choose windows from the grub > >>>>> menu). but when you use xen to boot /dev/hda, the grub on /dev/hda > >>>>> could be used to load the windows. Don''t know if it really works, > >>>>> don''t have a try now. > >>>>>> > >>>>>> -- > >>>>>> Z24 > >>>>>> http://www.mycomputingart.com/ > >>>>>> > >>>>> > >>>> > >>> > >>> _______________________________________________ > >>> Xen-devel mailing list > >>> Xen-devel@lists.xensource.com > >>> http://lists.xensource.com/xen-devel > >> > >> > >> > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Aug-07 08:02 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
D037C is not particularly interesting. It is just showing that the trap handler called halt() after dumping the register state. More interesting is cs:eip=10:d0800. This looks like the original trap-6 occurred at linear address (0x10<<4)+0xd0800 == 0xd0900. Is there anything interesting in the objdump at 0xd0900? (or 0xd0800, as I''m not 100% sure about the cs value). -- Keir On 7/8/07 08:58, "Brady Chen" <chenchp@gmail.com> wrote:> now I''m using the un-stable version to build hvmloader (only hvmloader > rebuild, xen and doman0 kernel is not touched), the same problem. > > (XEN) HVM1: Trap (0x6) while in real mode > (XEN) HVM1: eax D00 ecx 0 edx 71F ebx 71E > (XEN) HVM1: esp D74D4 ebp D7520 esi 0 edi D00 > (XEN) HVM1: trapno 6 errno 0 > (XEN) HVM1: eip D0800 cs 10 eflags 13046 > (XEN) HVM1: uesp D75B4 uss 2 > (XEN) HVM1: ves D4BC8 vds D4D26 vfs D07FE vgs D75B4 > (XEN) HVM1: cr0 50032 cr2 0 cr3 0 cr4 651 > (XEN) HVM1: > (XEN) HVM1: Halt called from %eip 0xD037C > > here is some snip from objdump, and i attach the whole objdump as the > attachment._______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Brady Chen
2007-Aug-07 08:22 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
Hi, here the output, you could get the whole dump from the attachment of my last mail. so, there should be a non-support instruction in 0xd0900 or 0xd0800? thanks d07ec: 8d 04 16 lea (%esi,%edx,1),%eax 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 d08e6: 8b 56 2c mov 0x2c(%esi),%edx d08e9: 89 f0 mov %esi,%eax d08eb: 89 1c 24 mov %ebx,(%esp) d08ee: e8 0d fe ff ff call d0700 <address> d08f3: 89 5c 24 0c mov %ebx,0xc(%esp) d08f7: 8b 56 2c mov 0x2c(%esi),%edx d08fa: 89 44 24 04 mov %eax,0x4(%esp) d08fe: c7 04 24 2e 4b 0d 00 movl $0xd4b2e,(%esp) d0905: 89 54 24 08 mov %edx,0x8(%esp) d0909: e8 c2 30 00 00 call d39d0 <printf> d090e: a1 04 76 0d 00 mov 0xd7604,%eax d0913: c7 04 24 43 4b 0d 00 movl $0xd4b43,(%esp) d091a: 89 44 24 04 mov %eax,0x4(%esp) d091e: e8 ad 30 00 00 call d39d0 <printf> d0923: 89 3c 24 mov %edi,(%esp) d0926: 8d 45 14 lea 0x14(%ebp),%eax d0929: 89 44 24 04 mov %eax,0x4(%esp) d092d: e8 7e 30 00 00 call d39b0 <vprintf On 8/7/07, Keir Fraser <keir@xensource.com> wrote:> D037C is not particularly interesting. It is just showing that the trap > handler called halt() after dumping the register state. More interesting is > cs:eip=10:d0800. This looks like the original trap-6 occurred at linear > address (0x10<<4)+0xd0800 == 0xd0900. Is there anything interesting in the > objdump at 0xd0900? (or 0xd0800, as I''m not 100% sure about the cs value). > > -- Keir > > On 7/8/07 08:58, "Brady Chen" <chenchp@gmail.com> wrote: > > > now I''m using the un-stable version to build hvmloader (only hvmloader > > rebuild, xen and doman0 kernel is not touched), the same problem. > > > > (XEN) HVM1: Trap (0x6) while in real mode > > (XEN) HVM1: eax D00 ecx 0 edx 71F ebx 71E > > (XEN) HVM1: esp D74D4 ebp D7520 esi 0 edi D00 > > (XEN) HVM1: trapno 6 errno 0 > > (XEN) HVM1: eip D0800 cs 10 eflags 13046 > > (XEN) HVM1: uesp D75B4 uss 2 > > (XEN) HVM1: ves D4BC8 vds D4D26 vfs D07FE vgs D75B4 > > (XEN) HVM1: cr0 50032 cr2 0 cr3 0 cr4 651 > > (XEN) HVM1: > > (XEN) HVM1: Halt called from %eip 0xD037C > > > > here is some snip from objdump, and i attach the whole objdump as the > > attachment. > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Aug-07 08:47 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
On 7/8/07 09:22, "Brady Chen" <chenchp@gmail.com> wrote:> Hi, here the output, you could get the whole dump from the attachment > of my last mail.Oh, I missed that!> so, there should be a non-support instruction in 0xd0900 or 0xd0800?Well, there is no instruction boundary at either of those addresses. Either the register dump is bogus or somehow we ended up jumping into the middle of an instruction inside vmxassist. Bogus. :-( You could try initialising the traceset variable in vmxassist/vm86.c to ~0 instead of 0. That should get you a whole load of extra tracing about exactly what vmxassist is emulating and where. We might be able to work out a bit more from that. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Brady Chen
2007-Aug-07 09:06 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
Hi Keir, the whole dmesg and a new objdump is attached. # tar zcvf xendmesg_vmxdump.tar.gz xen_dmesg vmxassist.objdump2 xen_dmesg vmxassist.objdump2 here are some snip for your convenience: (XEN) HVM2: 0x0000D71F: 0xD00:0x071F (0) data32 (XEN) HVM2: 0x0000D71F: 0xD00:0x071F (0) opc 0x83 (XEN) HVM2: 0x0000D71B: 0xD00:0x071B (0) %es: (XEN) HVM2: 0x0000D71B: 0xD00:0x071B (0) addr32 (XEN) HVM2: 0x0000D71D: 0xD00:0x071D (0) movw %ax, *0xD07FE (XEN) HVM2: Trap (0x6) while in real mode (XEN) HVM2: eax D00 ecx 0 edx 71F ebx 71E (XEN) HVM2: esp D74D4 ebp D7520 esi D74B0 edi D00 (XEN) HVM2: trapno 6 errno 0 (XEN) HVM2: eip D0800 cs 10 eflags 13046 (XEN) HVM2: uesp D75B4 uss 2 (XEN) HVM2: ves D4BC8 vds D4D26 vfs D07FE vgs D7534 (XEN) HVM2: cr0 50032 cr2 0 cr3 0 cr4 651 (XEN) HVM2: (XEN) HVM2: Halt called from %eip 0xD037C 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 d08f7: 8b 56 2c mov 0x2c(%esi),%edx d08fa: 89 44 24 04 mov %eax,0x4(%esp) d08fe: c7 04 24 2e 4b 0d 00 movl $0xd4b2e,(%esp) d0905: 89 54 24 08 mov %edx,0x8(%esp) d0909: e8 c2 30 00 00 call d39d0 <printf> d090e: a1 00 76 0d 00 mov 0xd7600,%eax the dmesg shows some instructions have being simulated. so they should be the codes just before d0900 or d0800, am i right? On 8/7/07, Keir Fraser <keir@xensource.com> wrote:> On 7/8/07 09:22, "Brady Chen" <chenchp@gmail.com> wrote: > > > Hi, here the output, you could get the whole dump from the attachment > > of my last mail. > > Oh, I missed that! > > > so, there should be a non-support instruction in 0xd0900 or 0xd0800? > > Well, there is no instruction boundary at either of those addresses. Either > the register dump is bogus or somehow we ended up jumping into the middle of > an instruction inside vmxassist. Bogus. :-( > > You could try initialising the traceset variable in vmxassist/vm86.c to ~0 > instead of 0. That should get you a whole load of extra tracing about > exactly what vmxassist is emulating and where. We might be able to work out > a bit more from that. > > -- Keir > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Aug-07 09:29 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
On 7/8/07 10:06, "Brady Chen" <chenchp@gmail.com> wrote:> the dmesg shows some instructions have being simulated. > so they should be the codes just before d0900 or d0800, am i right?No. What is happening is that vmxassist is trying to emulate as far as it can into real-mode execution at around linear address d71b-d71f, until it sees an instruction that it cannot decode. When it sees an instruction it does not understand it prints out "opc <opcode number>". Since there is no such output immediately before the trap, this means that vmxassist was still in its emulation loop and vmxassist itself crashed. This makes sense because the faulting eip is somewhere in vmxassist''s code (albeit not on an instruction boundary!). The faulting linear address is definitely d0800, so that is the interesting area of the vmxassist objdump. 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. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Aug-07 09:35 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
On 7/8/07 10:29, "Keir Fraser" <keir@xensource.com> 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@lists.xensource.com http://lists.xensource.com/xen-devel
Artur Linhart - Linux communication
2007-Aug-07 09:54 UTC
RE: [Xen-users] boot a existing windows in hvm domain
Hello, Yes, I communicated to this thread also. Exactly the same configuration I have on my notebook... My opinion is, either the boot into windows as Domu, nor the boot into Linux as a DomU (re-enter) is possible, or, if possible, then very unsafe - but I did not get working even the re-entrance of linux. I understand it so, if there is no underlaying mechanism like nfs allowing the synchronization of the write-accesses, the device where DomU is installed (it does not matter if it is a real physical device or virtual disk emulated through file or logical volume) must give to windows or other Domu operating system the possibility to control exclusively the write-access to this device (disk). Even the domain installed on logical volume will not start if the logical volume is mounted in Dom0 as read/write... And even if nfs is used, I think it is not a good idea run the system twice a time at the same time from the same physical location - I can imagine some services will not be started, because there are some locks already from the other system instance, data on teh disk can get confused or destroyed by the parallel access, etc.... So, from my point of view, it cannot work and even if it would be from some unclear reason possible it is not intended and not safe to do it so, like described below. With best regards, Archie. -----Original Message----- From: Brady Chen [mailto:chenchp@gmail.com] Sent: Tuesday, August 07, 2007 4:55 AM To: Z24; AL.LINUX@bcpraha.com; tygrawy@gazeta.pl Cc: xen-users@lists.xensource.com Subject: Re: [Xen-users] boot a existing windows in hvm domain Hi Z24, AL, ccing tygrawy@gazeta,pl, for I found he got the same issue. I tried in ThinkPad T60, /dev/sda1 -- windows /dev/sda2 -- Linux + Xen 3.1.0 in xen guest, the whole sda is mapped to virtual hda. disk = [ ''phy:/dev/sda, hda, w'' ] I could see the grub menu in xen guest, and could boot in to the linux (you know, it''s re-enter into the linux), but when I select windows from grub menu, it will hang after print "chainloader +1" the xen dmesg shows: (XEN) HVM1: Trap (0x6) while in real mode (XEN) HVM1: eax D00 ecx 0 edx 71F ebx 71E (XEN) HVM1: esp D7384 ebp D73D0 esi D7364 edi D00 (XEN) HVM1: trapno 6 errno 0 (XEN) HVM1: eip D0800 cs 10 eflags 13046 (XEN) HVM1: uesp D7474 uss 2 (XEN) HVM1: ves D4AB8 vds D4C1D vfs D07FE vgs D7474 (XEN) HVM1: cr0 50032 cr2 0 cr3 0 cr4 651 (XEN) HVM1: (XEN) HVM1: Halt called from %eip 0xD037 tygrawy: I found you have the same issue months ago, have you find out the reason? Thank you very much. http://lists.xensource.com/archives/html/xen-users/2007-07/msg00521.html On 8/2/07, Brady Chen <chenchp@gmail.com> wrote:> On 8/2/07, Z24 <z24@gmx.net> wrote: > > On Thu, 2 Aug 2007 17:47:59 +0800, you wrote: > > > > >thank you all, > > >looks like it''s possible. it''s great! > > > > > >Z24, > > >do you get the hardware issue Archie said, that''s my concern too. > > >you know, windows may be bluescreen if the hardware changes. > > > > Before booting the Windows domU I copied the current Windows HW > > Profile to a new HW Profile, then when I boot the domU I choose the > > new HW profile. > > The first time I booted the domU, Windows took some minutes more than > > usual to load, I suppose it was setting automatically the hardware > > drivers; the next time it booted only a little slower than when I boot > > it natively (due to virtualization). > > > thanks, I will have a try. > > > >and for your case, i think you could install another grub in thewindows disk> > > > What do you mean? > > Xen VM configuration with ''phy:/dev/hda,ioemu:hda,w'' only (hda is > > Windows disk) and grub-install on /dev/hda without mapping? > yup, install grub on /dev/hda, it will not be used when you not using > xen (i mean when you reboot your PC, and choose windows from the grub > menu). but when you use xen to boot /dev/hda, the grub on /dev/hda > could be used to load the windows. Don''t know if it really works, > don''t have a try now. > > > > -- > > Z24 > > http://www.mycomputingart.com/ > > >__________ Informace od NOD32 2440 (20070806) __________ Tato zprava byla proverena antivirovym systemem NOD32. http://www.nod32.cz _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Brady Chen
2007-Aug-07 10:30 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
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@xensource.com> wrote:> On 7/8/07 10:29, "Keir Fraser" <keir@xensource.com> 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@lists.xensource.com
http://lists.xensource.com/xen-devel
I understand, if use the windows partition carefully, and not modify the partition which linux located in. I think it should be ok. Just don''t have another disk to install windows separately :) On 8/7/07, Artur Linhart - Linux communication <AL.LINUX@bcpraha.com> wrote:> > Hello, > > Yes, I communicated to this thread also. Exactly the same > configuration I have on my notebook... > My opinion is, either the boot into windows as Domu, nor the boot > into Linux as a DomU (re-enter) is possible, or, if possible, then very > unsafe - but I did not get working even the re-entrance of linux. > I understand it so, if there is no underlaying mechanism like nfs > allowing the synchronization of the write-accesses, the device where DomU is > installed (it does not matter if it is a real physical device or virtual > disk emulated through file or logical volume) must give to windows or other > Domu operating system the possibility to control exclusively the > write-access to this device (disk). Even the domain installed on logical > volume will not start if the logical volume is mounted in Dom0 as > read/write... > And even if nfs is used, I think it is not a good idea run the > system twice a time at the same time from the same physical location - I can > imagine some services will not be started, because there are some locks > already from the other system instance, data on teh disk can get confused or > destroyed by the parallel access, etc.... > So, from my point of view, it cannot work and even if it would be > from some unclear reason possible it is not intended and not safe to do it > so, like described below. > > With best regards, Archie. > > -----Original Message----- > From: Brady Chen [mailto:chenchp@gmail.com] > Sent: Tuesday, August 07, 2007 4:55 AM > To: Z24; AL.LINUX@bcpraha.com; tygrawy@gazeta.pl > Cc: xen-users@lists.xensource.com > Subject: Re: [Xen-users] boot a existing windows in hvm domain > > Hi Z24, AL, > ccing tygrawy@gazeta,pl, for I found he got the same issue. > > I tried in ThinkPad T60, > /dev/sda1 -- windows > /dev/sda2 -- Linux + Xen 3.1.0 > > in xen guest, the whole sda is mapped to virtual hda. > disk = [ ''phy:/dev/sda, hda, w'' ] > > I could see the grub menu in xen guest, and could boot in to the linux > (you know, it''s re-enter into the linux), but when I select windows > from grub menu, it will hang after print "chainloader +1" > the xen dmesg shows: > (XEN) HVM1: Trap (0x6) while in real mode > (XEN) HVM1: eax D00 ecx 0 edx 71F ebx 71E > (XEN) HVM1: esp D7384 ebp D73D0 esi D7364 edi D00 > (XEN) HVM1: trapno 6 errno 0 > (XEN) HVM1: eip D0800 cs 10 eflags 13046 > (XEN) HVM1: uesp D7474 uss 2 > (XEN) HVM1: ves D4AB8 vds D4C1D vfs D07FE vgs D7474 > (XEN) HVM1: cr0 50032 cr2 0 cr3 0 cr4 651 > (XEN) HVM1: > (XEN) HVM1: Halt called from %eip 0xD037 > > tygrawy: > I found you have the same issue months ago, have you find out the > reason? Thank you very much. > > http://lists.xensource.com/archives/html/xen-users/2007-07/msg00521.html > > On 8/2/07, Brady Chen <chenchp@gmail.com> wrote: > > On 8/2/07, Z24 <z24@gmx.net> wrote: > > > On Thu, 2 Aug 2007 17:47:59 +0800, you wrote: > > > > > > >thank you all, > > > >looks like it''s possible. it''s great! > > > > > > > >Z24, > > > >do you get the hardware issue Archie said, that''s my concern too. > > > >you know, windows may be bluescreen if the hardware changes. > > > > > > Before booting the Windows domU I copied the current Windows HW > > > Profile to a new HW Profile, then when I boot the domU I choose the > > > new HW profile. > > > The first time I booted the domU, Windows took some minutes more than > > > usual to load, I suppose it was setting automatically the hardware > > > drivers; the next time it booted only a little slower than when I boot > > > it natively (due to virtualization). > > > > > thanks, I will have a try. > > > > > >and for your case, i think you could install another grub in the > windows disk > > > > > > What do you mean? > > > Xen VM configuration with ''phy:/dev/hda,ioemu:hda,w'' only (hda is > > > Windows disk) and grub-install on /dev/hda without mapping? > > yup, install grub on /dev/hda, it will not be used when you not using > > xen (i mean when you reboot your PC, and choose windows from the grub > > menu). but when you use xen to boot /dev/hda, the grub on /dev/hda > > could be used to load the windows. Don''t know if it really works, > > don''t have a try now. > > > > > > -- > > > Z24 > > > http://www.mycomputingart.com/ > > > > > > > __________ Informace od NOD32 2440 (20070806) __________ > > Tato zprava byla proverena antivirovym systemem NOD32. > http://www.nod32.cz > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Keir Fraser
2007-Aug-07 10:37 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
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@gmail.com> 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@xensource.com> wrote:
>> On 7/8/07 10:29, "Keir Fraser" <keir@xensource.com>
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@lists.xensource.com
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Brady Chen
2007-Aug-07 11:03 UTC
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@xensource.com> 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@gmail.com> 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@xensource.com> wrote: > >> On 7/8/07 10:29, "Keir Fraser" <keir@xensource.com> 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@lists.xensource.com > > http://lists.xensource.com/xen-devel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Brady Chen
2007-Aug-07 11:35 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
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@gmail.com> 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@xensource.com> 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@gmail.com>
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@xensource.com> wrote:
> > >> On 7/8/07 10:29, "Keir Fraser"
<keir@xensource.com> 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@lists.xensource.com
> > > http://lists.xensource.com/xen-devel
> >
> >
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Keir Fraser
2007-Aug-07 11:50 UTC
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@gmail.com> 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@gmail.com> 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@xensource.com> 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@gmail.com> 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@xensource.com> wrote: >>>>> On 7/8/07 10:29, "Keir Fraser" <keir@xensource.com> 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@lists.xensource.com >>>> http://lists.xensource.com/xen-devel >>> >>> >> > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Brady Chen
2007-Aug-07 16:06 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
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@xensource.com> 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@gmail.com> 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@gmail.com> 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@xensource.com> 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@gmail.com> 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@xensource.com> wrote:
> >>>>> On 7/8/07 10:29, "Keir Fraser"
<keir@xensource.com> 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@lists.xensource.com
> >>>> http://lists.xensource.com/xen-devel
> >>>
> >>>
> >>
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Keir Fraser
2007-Aug-07 16:26 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
Stack corruption/overflow, possibly? K. On 7/8/07 17:06, "Brady Chen" <chenchp@gmail.com> 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@xensource.com> 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@gmail.com> 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@gmail.com> 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@xensource.com> 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@gmail.com> 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@xensource.com> wrote: >>>>>>> On 7/8/07 10:29, "Keir Fraser" <keir@xensource.com> 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@lists.xensource.com >>>>>> http://lists.xensource.com/xen-devel >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xensource.com >>> http://lists.xensource.com/xen-devel >> >> > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Artur Linhart - Linux communication
2007-Aug-07 17:55 UTC
RE: [Xen-users] boot a existing windows in hvm domain
Hello, It is a question if there is something like "careful access" if we speak about Windows... :-) I think Windows OS will just want to get exclusive access independently on the fact how careful You will be... Good luck ;-) Archie -----Original Message----- From: xen-users-bounces@lists.xensource.com [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of Brady Chen Sent: Tuesday, August 07, 2007 12:36 PM To: Artur Linhart - Linux communication Cc: tygrawy@gazeta.pl; Z24; xen-users@lists.xensource.com Subject: Re: [Xen-users] boot a existing windows in hvm domain I understand, if use the windows partition carefully, and not modify the partition which linux located in. I think it should be ok. Just don''t have another disk to install windows separately :) On 8/7/07, Artur Linhart - Linux communication <AL.LINUX@bcpraha.com> wrote:> > Hello, > > Yes, I communicated to this thread also. Exactly the same > configuration I have on my notebook... > My opinion is, either the boot into windows as Domu, nor the boot > into Linux as a DomU (re-enter) is possible, or, if possible, then very > unsafe - but I did not get working even the re-entrance of linux. > I understand it so, if there is no underlaying mechanism like nfs > allowing the synchronization of the write-accesses, the device where DomUis> installed (it does not matter if it is a real physical device or virtual > disk emulated through file or logical volume) must give to windows orother> Domu operating system the possibility to control exclusively the > write-access to this device (disk). Even the domain installed on logical > volume will not start if the logical volume is mounted in Dom0 as > read/write... > And even if nfs is used, I think it is not a good idea run the > system twice a time at the same time from the same physical location - Ican> imagine some services will not be started, because there are some locks > already from the other system instance, data on teh disk can get confusedor> destroyed by the parallel access, etc.... > So, from my point of view, it cannot work and even if it would be > from some unclear reason possible it is not intended and not safe to do it > so, like described below. > > With best regards, Archie. > > -----Original Message----- > From: Brady Chen [mailto:chenchp@gmail.com] > Sent: Tuesday, August 07, 2007 4:55 AM > To: Z24; AL.LINUX@bcpraha.com; tygrawy@gazeta.pl > Cc: xen-users@lists.xensource.com > Subject: Re: [Xen-users] boot a existing windows in hvm domain > > Hi Z24, AL, > ccing tygrawy@gazeta,pl, for I found he got the same issue. > > I tried in ThinkPad T60, > /dev/sda1 -- windows > /dev/sda2 -- Linux + Xen 3.1.0 > > in xen guest, the whole sda is mapped to virtual hda. > disk = [ ''phy:/dev/sda, hda, w'' ] > > I could see the grub menu in xen guest, and could boot in to the linux > (you know, it''s re-enter into the linux), but when I select windows > from grub menu, it will hang after print "chainloader +1" > the xen dmesg shows: > (XEN) HVM1: Trap (0x6) while in real mode > (XEN) HVM1: eax D00 ecx 0 edx 71F ebx71E> (XEN) HVM1: esp D7384 ebp D73D0 esi D7364 ediD00> (XEN) HVM1: trapno 6 errno 0 > (XEN) HVM1: eip D0800 cs 10 eflags 13046 > (XEN) HVM1: uesp D7474 uss 2 > (XEN) HVM1: ves D4AB8 vds D4C1D vfs D07FE vgsD7474> (XEN) HVM1: cr0 50032 cr2 0 cr3 0 cr4651> (XEN) HVM1: > (XEN) HVM1: Halt called from %eip 0xD037 > > tygrawy: > I found you have the same issue months ago, have you find out the > reason? Thank you very much. > > http://lists.xensource.com/archives/html/xen-users/2007-07/msg00521.html > > On 8/2/07, Brady Chen <chenchp@gmail.com> wrote: > > On 8/2/07, Z24 <z24@gmx.net> wrote: > > > On Thu, 2 Aug 2007 17:47:59 +0800, you wrote: > > > > > > >thank you all, > > > >looks like it''s possible. it''s great! > > > > > > > >Z24, > > > >do you get the hardware issue Archie said, that''s my concern too. > > > >you know, windows may be bluescreen if the hardware changes. > > > > > > Before booting the Windows domU I copied the current Windows HW > > > Profile to a new HW Profile, then when I boot the domU I choose the > > > new HW profile. > > > The first time I booted the domU, Windows took some minutes more than > > > usual to load, I suppose it was setting automatically the hardware > > > drivers; the next time it booted only a little slower than when I boot > > > it natively (due to virtualization). > > > > > thanks, I will have a try. > > > > > >and for your case, i think you could install another grub in the > windows disk > > > > > > What do you mean? > > > Xen VM configuration with ''phy:/dev/hda,ioemu:hda,w'' only (hda is > > > Windows disk) and grub-install on /dev/hda without mapping? > > yup, install grub on /dev/hda, it will not be used when you not using > > xen (i mean when you reboot your PC, and choose windows from the grub > > menu). but when you use xen to boot /dev/hda, the grub on /dev/hda > > could be used to load the windows. Don''t know if it really works, > > don''t have a try now. > > > > > > -- > > > Z24 > > > http://www.mycomputingart.com/ > > > > > > > __________ Informace od NOD32 2440 (20070806) __________ > > Tato zprava byla proverena antivirovym systemem NOD32. > http://www.nod32.cz > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users __________ Informace od NOD32 2441 (20070807) __________ Tato zprava byla proverena antivirovym systemem NOD32. http://www.nod32.cz _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
yup, I think you are right, windows maybe try to scan all the partitions on the disk. but it''s worth to have a try. however, I''m still stuck by the windows boot issue, will let you know if it works. and any configuration examples about how to use a dummy file to simulate the linux partition, and let windows in xen will see the grub, and the windows partition? thanks On 8/8/07, Artur Linhart - Linux communication <AL.LINUX@bcpraha.com> wrote:> Hello, > > It is a question if there is something like "careful access" if we > speak about Windows... :-) I think Windows OS will just want to get > exclusive access independently on the fact how careful You will be... > > Good luck ;-) > > Archie > > -----Original Message----- > From: xen-users-bounces@lists.xensource.com > [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of Brady Chen > Sent: Tuesday, August 07, 2007 12:36 PM > To: Artur Linhart - Linux communication > Cc: tygrawy@gazeta.pl; Z24; xen-users@lists.xensource.com > Subject: Re: [Xen-users] boot a existing windows in hvm domain > > I understand, > if use the windows partition carefully, and not modify the partition > which linux located in. > I think it should be ok. Just don''t have another disk to install > windows separately :) > > On 8/7/07, Artur Linhart - Linux communication <AL.LINUX@bcpraha.com> wrote: > > > > Hello, > > > > Yes, I communicated to this thread also. Exactly the same > > configuration I have on my notebook... > > My opinion is, either the boot into windows as Domu, nor the boot > > into Linux as a DomU (re-enter) is possible, or, if possible, then very > > unsafe - but I did not get working even the re-entrance of linux. > > I understand it so, if there is no underlaying mechanism like nfs > > allowing the synchronization of the write-accesses, the device where DomU > is > > installed (it does not matter if it is a real physical device or virtual > > disk emulated through file or logical volume) must give to windows or > other > > Domu operating system the possibility to control exclusively the > > write-access to this device (disk). Even the domain installed on logical > > volume will not start if the logical volume is mounted in Dom0 as > > read/write... > > And even if nfs is used, I think it is not a good idea run the > > system twice a time at the same time from the same physical location - I > can > > imagine some services will not be started, because there are some locks > > already from the other system instance, data on teh disk can get confused > or > > destroyed by the parallel access, etc.... > > So, from my point of view, it cannot work and even if it would be > > from some unclear reason possible it is not intended and not safe to do it > > so, like described below. > > > > With best regards, Archie. > > > > -----Original Message----- > > From: Brady Chen [mailto:chenchp@gmail.com] > > Sent: Tuesday, August 07, 2007 4:55 AM > > To: Z24; AL.LINUX@bcpraha.com; tygrawy@gazeta.pl > > Cc: xen-users@lists.xensource.com > > Subject: Re: [Xen-users] boot a existing windows in hvm domain > > > > Hi Z24, AL, > > ccing tygrawy@gazeta,pl, for I found he got the same issue. > > > > I tried in ThinkPad T60, > > /dev/sda1 -- windows > > /dev/sda2 -- Linux + Xen 3.1.0 > > > > in xen guest, the whole sda is mapped to virtual hda. > > disk = [ ''phy:/dev/sda, hda, w'' ] > > > > I could see the grub menu in xen guest, and could boot in to the linux > > (you know, it''s re-enter into the linux), but when I select windows > > from grub menu, it will hang after print "chainloader +1" > > the xen dmesg shows: > > (XEN) HVM1: Trap (0x6) while in real mode > > (XEN) HVM1: eax D00 ecx 0 edx 71F ebx > 71E > > (XEN) HVM1: esp D7384 ebp D73D0 esi D7364 edi > D00 > > (XEN) HVM1: trapno 6 errno 0 > > (XEN) HVM1: eip D0800 cs 10 eflags 13046 > > (XEN) HVM1: uesp D7474 uss 2 > > (XEN) HVM1: ves D4AB8 vds D4C1D vfs D07FE vgs > D7474 > > (XEN) HVM1: cr0 50032 cr2 0 cr3 0 cr4 > 651 > > (XEN) HVM1: > > (XEN) HVM1: Halt called from %eip 0xD037 > > > > tygrawy: > > I found you have the same issue months ago, have you find out the > > reason? Thank you very much. > > > > http://lists.xensource.com/archives/html/xen-users/2007-07/msg00521.html > > > > On 8/2/07, Brady Chen <chenchp@gmail.com> wrote: > > > On 8/2/07, Z24 <z24@gmx.net> wrote: > > > > On Thu, 2 Aug 2007 17:47:59 +0800, you wrote: > > > > > > > > >thank you all, > > > > >looks like it''s possible. it''s great! > > > > > > > > > >Z24, > > > > >do you get the hardware issue Archie said, that''s my concern too. > > > > >you know, windows may be bluescreen if the hardware changes. > > > > > > > > Before booting the Windows domU I copied the current Windows HW > > > > Profile to a new HW Profile, then when I boot the domU I choose the > > > > new HW profile. > > > > The first time I booted the domU, Windows took some minutes more than > > > > usual to load, I suppose it was setting automatically the hardware > > > > drivers; the next time it booted only a little slower than when I boot > > > > it natively (due to virtualization). > > > > > > > thanks, I will have a try. > > > > > > > >and for your case, i think you could install another grub in the > > windows disk > > > > > > > > What do you mean? > > > > Xen VM configuration with ''phy:/dev/hda,ioemu:hda,w'' only (hda is > > > > Windows disk) and grub-install on /dev/hda without mapping? > > > yup, install grub on /dev/hda, it will not be used when you not using > > > xen (i mean when you reboot your PC, and choose windows from the grub > > > menu). but when you use xen to boot /dev/hda, the grub on /dev/hda > > > could be used to load the windows. Don''t know if it really works, > > > don''t have a try now. > > > > > > > > -- > > > > Z24 > > > > http://www.mycomputingart.com/ > > > > > > > > > > > __________ Informace od NOD32 2440 (20070806) __________ > > > > Tato zprava byla proverena antivirovym systemem NOD32. > > http://www.nod32.cz > > > > > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users > > __________ Informace od NOD32 2441 (20070807) __________ > > Tato zprava byla proverena antivirovym systemem NOD32. > http://www.nod32.cz > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Brady Chen
2007-Aug-08 07:37 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
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@xensource.com> wrote:> Stack corruption/overflow, possibly? > > K. > > On 7/8/07 17:06, "Brady Chen" <chenchp@gmail.com> 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@xensource.com> 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@gmail.com> 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@gmail.com> 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@xensource.com> 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@gmail.com> 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@xensource.com> wrote: > >>>>>>> On 7/8/07 10:29, "Keir Fraser" <keir@xensource.com> 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@lists.xensource.com > >>>>>> http://lists.xensource.com/xen-devel > >>>>> > >>>>> > >>>> > >>> > >>> _______________________________________________ > >>> Xen-devel mailing list > >>> Xen-devel@lists.xensource.com > >>> http://lists.xensource.com/xen-devel > >> > >> > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Brady Chen
2007-Aug-08 08:25 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
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@gmail.com> 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@xensource.com> wrote: > > Stack corruption/overflow, possibly? > > > > K. > > > > On 7/8/07 17:06, "Brady Chen" <chenchp@gmail.com> 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@xensource.com> 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@gmail.com> 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@gmail.com> 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@xensource.com> 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@gmail.com> 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@xensource.com> wrote: > > >>>>>>> On 7/8/07 10:29, "Keir Fraser" <keir@xensource.com> 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@lists.xensource.com > > >>>>>> http://lists.xensource.com/xen-devel > > >>>>> > > >>>>> > > >>>> > > >>> > > >>> _______________________________________________ > > >>> Xen-devel mailing list > > >>> Xen-devel@lists.xensource.com > > >>> http://lists.xensource.com/xen-devel > > >> > > >> > > > > > > _______________________________________________ > > > Xen-devel mailing list > > > Xen-devel@lists.xensource.com > > > http://lists.xensource.com/xen-devel > > > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Aug-08 08:41 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
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@gmail.com> 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@gmail.com> 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@xensource.com> wrote: >>> Stack corruption/overflow, possibly? >>> >>> K. >>> >>> On 7/8/07 17:06, "Brady Chen" <chenchp@gmail.com> 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@xensource.com> 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@gmail.com> 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@gmail.com> 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@xensource.com> 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@gmail.com> 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@xensource.com> wrote: >>>>>>>>>> On 7/8/07 10:29, "Keir Fraser" <keir@xensource.com> 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@lists.xensource.com >>>>>>>>> http://lists.xensource.com/xen-devel >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Xen-devel mailing list >>>>>> Xen-devel@lists.xensource.com >>>>>> http://lists.xensource.com/xen-devel >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Xen-devel mailing list >>>> Xen-devel@lists.xensource.com >>>> http://lists.xensource.com/xen-devel >>> >>> >> > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Brady Chen
2007-Aug-08 09:38 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
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@xensource.com> 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@gmail.com> 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@gmail.com> 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@xensource.com> wrote: > >>> Stack corruption/overflow, possibly? > >>> > >>> K. > >>> > >>> On 7/8/07 17:06, "Brady Chen" <chenchp@gmail.com> 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@xensource.com> 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@gmail.com> 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@gmail.com> 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@xensource.com> 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@gmail.com> 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@xensource.com> wrote: > >>>>>>>>>> On 7/8/07 10:29, "Keir Fraser" <keir@xensource.com> 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@lists.xensource.com > >>>>>>>>> http://lists.xensource.com/xen-devel > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Xen-devel mailing list > >>>>>> Xen-devel@lists.xensource.com > >>>>>> http://lists.xensource.com/xen-devel > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Xen-devel mailing list > >>>> Xen-devel@lists.xensource.com > >>>> http://lists.xensource.com/xen-devel > >>> > >>> > >> > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Aug-08 10:26 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
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@gmail.com> 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@xensource.com> 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@gmail.com> 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@gmail.com> 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@xensource.com> wrote: >>>>> Stack corruption/overflow, possibly? >>>>> >>>>> K. >>>>> >>>>> On 7/8/07 17:06, "Brady Chen" <chenchp@gmail.com> 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@xensource.com> 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@gmail.com> 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@gmail.com> 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@xensource.com> 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@gmail.com> 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@xensource.com> wrote: >>>>>>>>>>>> On 7/8/07 10:29, "Keir Fraser" <keir@xensource.com> 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@lists.xensource.com >>>>>>>>>>> http://lists.xensource.com/xen-devel >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Xen-devel mailing list >>>>>>>> Xen-devel@lists.xensource.com >>>>>>>> http://lists.xensource.com/xen-devel >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Xen-devel mailing list >>>>>> Xen-devel@lists.xensource.com >>>>>> http://lists.xensource.com/xen-devel >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xensource.com >>> http://lists.xensource.com/xen-devel >> >> > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Artur Linhart - Linux communication
2007-Aug-08 10:53 UTC
RE: [Xen-users] boot a existing windows in hvm domain
Hello, The way with the simulated linux partition exists till now only in my head :-) But IMHO could be only used in the case windows is installed on second physical disk, not only on some partition on the same physical disk. I never did it directly by myself, but, if, for example linux is installed on /dev/sda and windows on /dev/sdb on some partition /dev/sdbx, then I think, You can create a file, install or dd Your boot directory with Grub there, possibly copy or initialize somehow the first 512 bytes of the file with the MBR and then You could have just file image with the grub and boot possibility, where You can select boot into windows (or other system installed on some other disk). I think it should be possible, it is very similar to create a boot floppy with grub installed on it. I did not have time to try it itself, in the end I gave it up - I did not have some computer, where windows would been installed on the second physical disk... The configuration in SXP could then look like disk = [ ''file:/some_dir/grub_boot_image.img,hda,r'', ''phy:/dev/sdb,hdb,w'' ] With best regards Artur -----Original Message----- From: Brady Chen [mailto:chenchp@gmail.com] Sent: Wednesday, August 08, 2007 5:16 AM To: Artur Linhart - Linux communication Cc: tygrawy@gazeta.pl; Z24; xen-users@lists.xensource.com Subject: Re: [Xen-users] boot a existing windows in hvm domain yup, I think you are right, windows maybe try to scan all the partitions on the disk. but it''s worth to have a try. however, I''m still stuck by the windows boot issue, will let you know if it works. and any configuration examples about how to use a dummy file to simulate the linux partition, and let windows in xen will see the grub, and the windows partition? thanks On 8/8/07, Artur Linhart - Linux communication <AL.LINUX@bcpraha.com> wrote:> Hello, > > It is a question if there is something like "careful access" if we > speak about Windows... :-) I think Windows OS will just want to get > exclusive access independently on the fact how careful You will be... > > Good luck ;-) > > Archie > > -----Original Message----- > From: xen-users-bounces@lists.xensource.com > [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of Brady Chen > Sent: Tuesday, August 07, 2007 12:36 PM > To: Artur Linhart - Linux communication > Cc: tygrawy@gazeta.pl; Z24; xen-users@lists.xensource.com > Subject: Re: [Xen-users] boot a existing windows in hvm domain > > I understand, > if use the windows partition carefully, and not modify the partition > which linux located in. > I think it should be ok. Just don''t have another disk to install > windows separately :) > > On 8/7/07, Artur Linhart - Linux communication <AL.LINUX@bcpraha.com>wrote:> > > > Hello, > > > > Yes, I communicated to this thread also. Exactly the same > > configuration I have on my notebook... > > My opinion is, either the boot into windows as Domu, nor theboot> > into Linux as a DomU (re-enter) is possible, or, if possible, then very > > unsafe - but I did not get working even the re-entrance of linux. > > I understand it so, if there is no underlaying mechanism likenfs> > allowing the synchronization of the write-accesses, the device whereDomU> is > > installed (it does not matter if it is a real physical device or virtual > > disk emulated through file or logical volume) must give to windows or > other > > Domu operating system the possibility to control exclusively the > > write-access to this device (disk). Even the domain installed on logical > > volume will not start if the logical volume is mounted in Dom0 as > > read/write... > > And even if nfs is used, I think it is not a good idea run the > > system twice a time at the same time from the same physical location - I > can > > imagine some services will not be started, because there are some locks > > already from the other system instance, data on teh disk can getconfused> or > > destroyed by the parallel access, etc.... > > So, from my point of view, it cannot work and even if it wouldbe> > from some unclear reason possible it is not intended and not safe to doit> > so, like described below. > > > > With best regards, Archie. > > > > -----Original Message----- > > From: Brady Chen [mailto:chenchp@gmail.com] > > Sent: Tuesday, August 07, 2007 4:55 AM > > To: Z24; AL.LINUX@bcpraha.com; tygrawy@gazeta.pl > > Cc: xen-users@lists.xensource.com > > Subject: Re: [Xen-users] boot a existing windows in hvm domain > > > > Hi Z24, AL, > > ccing tygrawy@gazeta,pl, for I found he got the same issue. > > > > I tried in ThinkPad T60, > > /dev/sda1 -- windows > > /dev/sda2 -- Linux + Xen 3.1.0 > > > > in xen guest, the whole sda is mapped to virtual hda. > > disk = [ ''phy:/dev/sda, hda, w'' ] > > > > I could see the grub menu in xen guest, and could boot in to the linux > > (you know, it''s re-enter into the linux), but when I select windows > > from grub menu, it will hang after print "chainloader +1" > > the xen dmesg shows: > > (XEN) HVM1: Trap (0x6) while in real mode > > (XEN) HVM1: eax D00 ecx 0 edx 71F ebx > 71E > > (XEN) HVM1: esp D7384 ebp D73D0 esi D7364 edi > D00 > > (XEN) HVM1: trapno 6 errno 0 > > (XEN) HVM1: eip D0800 cs 10 eflags 13046 > > (XEN) HVM1: uesp D7474 uss 2 > > (XEN) HVM1: ves D4AB8 vds D4C1D vfs D07FE vgs > D7474 > > (XEN) HVM1: cr0 50032 cr2 0 cr3 0 cr4 > 651 > > (XEN) HVM1: > > (XEN) HVM1: Halt called from %eip 0xD037 > > > > tygrawy: > > I found you have the same issue months ago, have you find out the > > reason? Thank you very much. > > > > http://lists.xensource.com/archives/html/xen-users/2007-07/msg00521.html > > > > On 8/2/07, Brady Chen <chenchp@gmail.com> wrote: > > > On 8/2/07, Z24 <z24@gmx.net> wrote: > > > > On Thu, 2 Aug 2007 17:47:59 +0800, you wrote: > > > > > > > > >thank you all, > > > > >looks like it''s possible. it''s great! > > > > > > > > > >Z24, > > > > >do you get the hardware issue Archie said, that''s my concern too. > > > > >you know, windows may be bluescreen if the hardware changes. > > > > > > > > Before booting the Windows domU I copied the current Windows HW > > > > Profile to a new HW Profile, then when I boot the domU I choose the > > > > new HW profile. > > > > The first time I booted the domU, Windows took some minutes morethan> > > > usual to load, I suppose it was setting automatically the hardware > > > > drivers; the next time it booted only a little slower than when Iboot> > > > it natively (due to virtualization). > > > > > > > thanks, I will have a try. > > > > > > > >and for your case, i think you could install another grub in the > > windows disk > > > > > > > > What do you mean? > > > > Xen VM configuration with ''phy:/dev/hda,ioemu:hda,w'' only (hda is > > > > Windows disk) and grub-install on /dev/hda without mapping? > > > yup, install grub on /dev/hda, it will not be used when you not using > > > xen (i mean when you reboot your PC, and choose windows from the grub > > > menu). but when you use xen to boot /dev/hda, the grub on /dev/hda > > > could be used to load the windows. Don''t know if it really works, > > > don''t have a try now. > > > > > > > > -- > > > > Z24 > > > > http://www.mycomputingart.com/ > > > > > > > > > > > __________ Informace od NOD32 2440 (20070806) __________ > > > > Tato zprava byla proverena antivirovym systemem NOD32. > > http://www.nod32.cz > > > > > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users > > __________ Informace od NOD32 2441 (20070807) __________ > > Tato zprava byla proverena antivirovym systemem NOD32. > http://www.nod32.cz > > >__________ Informace od NOD32 2442 (20070807) __________ Tato zprava byla proverena antivirovym systemem NOD32. http://www.nod32.cz _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Brady Chen
2007-Aug-08 12:12 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
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@xensource.com> 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@gmail.com> 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@xensource.com> 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@gmail.com> 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@gmail.com> 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@xensource.com> wrote: > >>>>> Stack corruption/overflow, possibly? > >>>>> > >>>>> K. > >>>>> > >>>>> On 7/8/07 17:06, "Brady Chen" <chenchp@gmail.com> 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@xensource.com> 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@gmail.com> 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@gmail.com> 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@xensource.com> 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@gmail.com> 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@xensource.com> wrote: > >>>>>>>>>>>> On 7/8/07 10:29, "Keir Fraser" <keir@xensource.com> 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@lists.xensource.com > >>>>>>>>>>> http://lists.xensource.com/xen-devel > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Xen-devel mailing list > >>>>>>>> Xen-devel@lists.xensource.com > >>>>>>>> http://lists.xensource.com/xen-devel > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Xen-devel mailing list > >>>>>> Xen-devel@lists.xensource.com > >>>>>> http://lists.xensource.com/xen-devel > >>>>> > >>>>> > >>>> > >>> > >>> _______________________________________________ > >>> Xen-devel mailing list > >>> Xen-devel@lists.xensource.com > >>> http://lists.xensource.com/xen-devel > >> > >> > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Aug-08 13:32 UTC
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@gmail.com> 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@xensource.com> 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@gmail.com> 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@xensource.com> 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@gmail.com> 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@gmail.com> 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@xensource.com> wrote: >>>>>>> Stack corruption/overflow, possibly? >>>>>>> >>>>>>> K. >>>>>>> >>>>>>> On 7/8/07 17:06, "Brady Chen" <chenchp@gmail.com> 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@xensource.com> 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@gmail.com> 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@gmail.com> 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@xensource.com> 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@gmail.com> 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@xensource.com> wrote: >>>>>>>>>>>> On 7/8/07 10:29, "Keir Fraser" <keir@xensource.com> 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@lists.xensource.com >>>>>>>>>>>> http://lists.xensource.com/xen-devel >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Xen-devel mailing list >>>>>>>>>> Xen-devel@lists.xensource.com >>>>>>>>>> http://lists.xensource.com/xen-devel >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Xen-devel mailing list >>>>>>>> Xen-devel@lists.xensource.com >>>>>>>> http://lists.xensource.com/xen-devel >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Xen-devel mailing list >>>>> Xen-devel@lists.xensource.com >>>>> http://lists.xensource.com/xen-devel >>>> >>>> >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xensource.com >>> http://lists.xensource.com/xen-devel >> >> > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mats Petersson
2007-Aug-08 14:52 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
At 14:32 08/08/2007, Keir Fraser 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 retAny chance that the segment(s) involved are "big-real-mode"? -- Mats>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@gmail.com> 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@xensource.com> 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@gmail.com> 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@xensource.com> 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@gmail.com> 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@gmail.com> 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@xensource.com> wrote: > >>>>>>> Stack corruption/overflow, possibly? > >>>>>>> > >>>>>>> K. > >>>>>>> > >>>>>>> On 7/8/07 17:06, "Brady Chen" <chenchp@gmail.com> 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@xensource.com> 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@gmail.com> 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@gmail.com> 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@xensource.com> 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@gmail.com> 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@xensource.com> wrote: > >>>>>>>>>>>> On 7/8/07 10:29, "Keir Fraser" <keir@xensource.com> 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@lists.xensource.com > >>>>>>>>>>>> http://lists.xensource.com/xen-devel > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> Xen-devel mailing list > >>>>>>>>>> Xen-devel@lists.xensource.com > >>>>>>>>>> http://lists.xensource.com/xen-devel > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Xen-devel mailing list > >>>>>>>> Xen-devel@lists.xensource.com > >>>>>>>> http://lists.xensource.com/xen-devel > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Xen-devel mailing list > >>>>> Xen-devel@lists.xensource.com > >>>>> http://lists.xensource.com/xen-devel > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> Xen-devel mailing list > >>> Xen-devel@lists.xensource.com > >>> http://lists.xensource.com/xen-devel > >> > >> > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > >_______________________________________________ >Xen-devel mailing list >Xen-devel@lists.xensource.com >http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Brady Chen
2007-Aug-08 15:42 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
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@xensource.com> 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@gmail.com> 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@xensource.com> 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@gmail.com> 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@xensource.com> 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@gmail.com> 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@gmail.com> 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@xensource.com> wrote: > >>>>>>> Stack corruption/overflow, possibly? > >>>>>>> > >>>>>>> K. > >>>>>>> > >>>>>>> On 7/8/07 17:06, "Brady Chen" <chenchp@gmail.com> 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@xensource.com> 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@gmail.com> 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@gmail.com> 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@xensource.com> 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@gmail.com> 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@xensource.com> wrote: > >>>>>>>>>>>> On 7/8/07 10:29, "Keir Fraser" <keir@xensource.com> 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@lists.xensource.com > >>>>>>>>>>>> http://lists.xensource.com/xen-devel > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> Xen-devel mailing list > >>>>>>>>>> Xen-devel@lists.xensource.com > >>>>>>>>>> http://lists.xensource.com/xen-devel > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Xen-devel mailing list > >>>>>>>> Xen-devel@lists.xensource.com > >>>>>>>> http://lists.xensource.com/xen-devel > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Xen-devel mailing list > >>>>> Xen-devel@lists.xensource.com > >>>>> http://lists.xensource.com/xen-devel > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> Xen-devel mailing list > >>> Xen-devel@lists.xensource.com > >>> http://lists.xensource.com/xen-devel > >> > >> > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Brady Chen
2007-Aug-08 15:50 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
"big-real-mode"? is it something related to PAE? my CPU is Intel T2400, Centrino Duo thanks [root@localhost firmware]# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 14 model name : Genuine Intel(R) CPU T2400 @ 1.83GHz stepping : 8 cpu MHz : 1828.831 cache size : 2048 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc pni monitor vmx est tm2 xtpr bogomips : 3660.35 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 14 model name : Genuine Intel(R) CPU T2400 @ 1.83GHz stepping : 8 cpu MHz : 1828.831 cache size : 2048 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc up pni monitor vmx est tm2 xtprbogomips : 3660.35 On 8/8/07, Mats Petersson <mats@planetcatfish.com> wrote:> At 14:32 08/08/2007, Keir Fraser 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 > > > Any chance that the segment(s) involved are "big-real-mode"? > > -- > Mats_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Aug-08 16:19 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
No, it''s a processor mode halfway between real mode and protected mode which all x86 processors support, but which vmxassist is really rather bad at handling. If this is a big-real-mode copy loop then that might explain why the loop is executing so bizarrely, and may mean you are out of luck until we retire vmxassist. -- Keir On 8/8/07 16:50, "Brady Chen" <chenchp@gmail.com> wrote:> "big-real-mode"? is it something related to PAE? my CPU is Intel > T2400, Centrino Duo > thanks > > [root@localhost firmware]# cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 14 > model name : Genuine Intel(R) CPU T2400 @ 1.83GHz > stepping : 8 > cpu MHz : 1828.831 > cache size : 2048 KB > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 10 > wp : yes > flags : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat > clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc pni > monitor vmx est tm2 xtpr > bogomips : 3660.35 > > processor : 1 > vendor_id : GenuineIntel > cpu family : 6 > model : 14 > model name : Genuine Intel(R) CPU T2400 @ 1.83GHz > stepping : 8 > cpu MHz : 1828.831 > cache size : 2048 KB > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 10 > wp : yes > flags : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat > clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc up pni > monitor vmx est tm2 xtprbogomips : 3660.35 > > > On 8/8/07, Mats Petersson <mats@planetcatfish.com> wrote: >> At 14:32 08/08/2007, Keir Fraser 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 >> >> >> Any chance that the segment(s) involved are "big-real-mode"? >> >> -- >> Mats > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mats Petersson
2007-Aug-08 17:45 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
At 17:19 08/08/2007, Keir Fraser wrote:>No, it''s a processor mode halfway between real mode and protected mode which >all x86 processors support, but which vmxassist is really rather bad at >handling. If this is a big-real-mode copy loop then that might explain why >the loop is executing so bizarrely, and may mean you are out of luck until >we retire vmxassist.And the fact that EDI is 0xC33FE when it tries to write to the memory at address of EDI indicates that it''s Big-Real-Mode. In real-mode, any register access beyond segment+0xFFFF is a GP-fault on 386 and later processors. To get around this and simplify the process of for example loading large chunks of data into memory, someone figured out that segment register limits (and base-address) is not being RESET by the processor when resetting the protected-mode bit in CR0, so one can go into protected mode, load a segment register with a bigger limit (e.g. a "no limit" of 4GB), and a base-addres of (say) zero. Unfortunately, since VMXassist uses the VM806 mode of the processor, it doesn''t support transitions back and forth between protected mode with segment registers preserved (you can''t run in Real Mode with VMX enabled). The other option for possibly getting this working (plug for my former employer) is to use an AMD processor, as that supports "real-mode virtualization", so you can run real-mode with "SVM" enabled, and in this case, the segment registers can be manipulated in protected mode, and then go back to real-mode, without any loss of segment data. As Keir hints, there is work to "remove" the VMXassist mode (which by all accounts, and I don''t think I''m offending anyone by saying this, is a quick hack to get around the fact that real-mode code is needed to boot the OS). -- Mats> -- Keir > >On 8/8/07 16:50, "Brady Chen" <chenchp@gmail.com> wrote: > > > "big-real-mode"? is it something related to PAE? my CPU is Intel > > T2400, Centrino Duo > > thanks > > > > [root@localhost firmware]# cat /proc/cpuinfo > > processor : 0 > > vendor_id : GenuineIntel > > cpu family : 6 > > model : 14 > > model name : Genuine Intel(R) CPU T2400 @ 1.83GHz > > stepping : 8 > > cpu MHz : 1828.831 > > cache size : 2048 KB > > fdiv_bug : no > > hlt_bug : no > > f00f_bug : no > > coma_bug : no > > fpu : yes > > fpu_exception : yes > > cpuid level : 10 > > wp : yes > > flags : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat > > clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc pni > > monitor vmx est tm2 xtpr > > bogomips : 3660.35 > > > > processor : 1 > > vendor_id : GenuineIntel > > cpu family : 6 > > model : 14 > > model name : Genuine Intel(R) CPU T2400 @ 1.83GHz > > stepping : 8 > > cpu MHz : 1828.831 > > cache size : 2048 KB > > fdiv_bug : no > > hlt_bug : no > > f00f_bug : no > > coma_bug : no > > fpu : yes > > fpu_exception : yes > > cpuid level : 10 > > wp : yes > > flags : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat > > clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc up pni > > monitor vmx est tm2 xtprbogomips : 3660.35 > > > > > > On 8/8/07, Mats Petersson <mats@planetcatfish.com> wrote: > >> At 14:32 08/08/2007, Keir Fraser 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 > >> > >> > >> Any chance that the segment(s) involved are "big-real-mode"? > >> > >> -- > >> Mats > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Aug-08 20:26 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
On 8/8/07 18:45, "Mats Petersson" <mats@planetcatfish.com> wrote:> At 17:19 08/08/2007, Keir Fraser wrote: >> No, it''s a processor mode halfway between real mode and protected mode which >> all x86 processors support, but which vmxassist is really rather bad at >> handling. If this is a big-real-mode copy loop then that might explain why >> the loop is executing so bizarrely, and may mean you are out of luck until >> we retire vmxassist. > > And the fact that EDI is 0xC33FE when it tries to write to the memory > at address of EDI indicates that it''s Big-Real-Mode.Yes, that''s a giveaway. So I think the ''fix'' here is to not try booting your native Windows partition on Xen. It''s not likely to work too well anyway, as it''ll look like all your hardware has changed, causing activation problems and also big driver changes whenever you switch between running on Xen and running natively. You''re better off having a dedicated Xen Windows installation, perhaps on an LVM partition. The problems that others have been seeing are quite likely not the same root cause as yours. Most times there''s an early boot problem it will end up with a trap and backtrace in vmxassist, when running on Intel CPUs. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Brady Chen
2007-Aug-09 03:05 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
Keir, Mats, Archie, and all others Thank you guys all. I just read this thread:http://lists.xensource.com/archives/html/xen-devel/2006-05/msg01442.html seems Randy Thelen tried to fix this issue one year ago, unfortunately that patch doesn''t work for me. Finally I think we have the conclusion that I have to give it up on my T60 Laptop now. But I''d like to try in this way: install windows in xen hvm guest, and then try to boot it in native environment. Hope it works. BTW, Keir, Mats, Any plan/schedule to support a full functional real mode simulator? Or do you know anyone are working on this? thanks On 8/9/07, Keir Fraser <keir@xensource.com> wrote:> On 8/8/07 18:45, "Mats Petersson" <mats@planetcatfish.com> wrote: > > > At 17:19 08/08/2007, Keir Fraser wrote: > >> No, it''s a processor mode halfway between real mode and protected mode which > >> all x86 processors support, but which vmxassist is really rather bad at > >> handling. If this is a big-real-mode copy loop then that might explain why > >> the loop is executing so bizarrely, and may mean you are out of luck until > >> we retire vmxassist. > > > > And the fact that EDI is 0xC33FE when it tries to write to the memory > > at address of EDI indicates that it''s Big-Real-Mode. > > Yes, that''s a giveaway. > > So I think the ''fix'' here is to not try booting your native Windows > partition on Xen. It''s not likely to work too well anyway, as it''ll look > like all your hardware has changed, causing activation problems and also big > driver changes whenever you switch between running on Xen and running > natively. > > You''re better off having a dedicated Xen Windows installation, perhaps on an > LVM partition. > > The problems that others have been seeing are quite likely not the same root > cause as yours. Most times there''s an early boot problem it will end up with > a trap and backtrace in vmxassist, when running on Intel CPUs. > > -- Keir > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Brady Chen
2007-Aug-09 04:01 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
another question: The same windows installation CD could be used in xen guest. So why windows bootloader use Big-Real-Mode for the native installation, but not use the mode for Xen-HVM guest installation? Thanks, On 8/9/07, Brady Chen <chenchp@gmail.com> wrote:> Keir, Mats, Archie, and all others > Thank you guys all. > > I just read this > thread:http://lists.xensource.com/archives/html/xen-devel/2006-05/msg01442.html > > seems Randy Thelen tried to fix this issue one year ago, unfortunately > that patch doesn''t work for me. > > Finally I think we have the conclusion that I have to give it up on my > T60 Laptop now. > But I''d like to try in this way: > install windows in xen hvm guest, and then try to boot it in native > environment. Hope it works. > > BTW, Keir, Mats, Any plan/schedule to support a full functional real > mode simulator? Or do you know anyone are working on this? thanks > > > > On 8/9/07, Keir Fraser <keir@xensource.com> wrote: > > On 8/8/07 18:45, "Mats Petersson" <mats@planetcatfish.com> wrote: > > > > > At 17:19 08/08/2007, Keir Fraser wrote: > > >> No, it''s a processor mode halfway between real mode and protected mode which > > >> all x86 processors support, but which vmxassist is really rather bad at > > >> handling. If this is a big-real-mode copy loop then that might explain why > > >> the loop is executing so bizarrely, and may mean you are out of luck until > > >> we retire vmxassist. > > > > > > And the fact that EDI is 0xC33FE when it tries to write to the memory > > > at address of EDI indicates that it''s Big-Real-Mode. > > > > Yes, that''s a giveaway. > > > > So I think the ''fix'' here is to not try booting your native Windows > > partition on Xen. It''s not likely to work too well anyway, as it''ll look > > like all your hardware has changed, causing activation problems and also big > > driver changes whenever you switch between running on Xen and running > > natively. > > > > You''re better off having a dedicated Xen Windows installation, perhaps on an > > LVM partition. > > > > The problems that others have been seeing are quite likely not the same root > > cause as yours. Most times there''s an early boot problem it will end up with > > a trap and backtrace in vmxassist, when running on Intel CPUs. > > > > -- Keir > > > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Aug-09 07:10 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
On 9/8/07 05:01, "Brady Chen" <chenchp@gmail.com> wrote:> another question: > The same windows installation CD could be used in xen guest. So why > windows bootloader use Big-Real-Mode for the native installation, but > not use the mode for Xen-HVM guest installation?Is this a retail Windows install CD, or an OEM CD supplied with your laptop? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Aug-09 07:13 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
On 9/8/07 04:05, "Brady Chen" <chenchp@gmail.com> wrote:> Finally I think we have the conclusion that I have to give it up on my > T60 Laptop now. > But I''d like to try in this way: > install windows in xen hvm guest, and then try to boot it in native > environment. Hope it works.Neither way round is going to work very well. The platform hardware will look (to Windows) to be entirely different in the two cases. Thus it will most liekly require you to re-activate your license. Also it''ll have the wrong drivers installed and hence you''ll have a bunch of driver re-installation every time you switch between native and Xen.> BTW, Keir, Mats, Any plan/schedule to support a full functional real > mode simulator? Or do you know anyone are working on this? thanksThere''s a plan, but not much of a schedule. Some of the cleanup work I''ve been doing in xen-unstable just now will help. I''d like to think we''ll have it done by Xen 3.3; Xen 3.2 is probably too close at this point. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Brady Chen
2007-Aug-09 10:35 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
> Is this a retail Windows install CD, or an OEM CD supplied with your laptop?it''s an OEM CD Thanks -Brady _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Brady Chen
2007-Aug-09 10:40 UTC
Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
> Neither way round is going to work very well. The platform hardware will > look (to Windows) to be entirely different in the two cases. Thus it will > most liekly require you to re-activate your license. Also it''ll have the > wrong drivers installed and hence you''ll have a bunch of driver > re-installation every time you switch between native and Xen.re-activate maybe the issue. For the hardware drivers, z24 said that he got it works by selecting the hardware profile of windows. here is the thread: http://lists.xensource.com/archives/html/xen-users/2007-02/msg00822.html I''d like to have a try.> There''s a plan, but not much of a schedule. Some of the cleanup work I''ve > been doing in xen-unstable just now will help. I''d like to think we''ll have > it done by Xen 3.3; Xen 3.2 is probably too close at this point.thank you very much, is there any time table(a document or a link) about the release? I''m new to xen, and don''t know the frequency of release. -Brady _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel